Quantcast

Patch rendering

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Patch rendering

James C. Wilson

So I've got a potential bug relating to layered patch rendering...

  I've got a slide node with a blank, opaque background. Over the background there are two patches: One, is a wider-then-background image which scrolls back and forth over the background. The second, is a PNG with a part in the middle made transparent, so you can see the scrolling image behind it. It all works fine, however, I can see a seam, one pixel wide, running on the left and right edges of the patch, peeking down onto the scrolling image and the opaque background.

    This seam is also present in another node where the patch underneath is smaller then the background and not scrollling.

    If the cause of this is well known I'd appreciate a heads-up. I've already checked the PNG to see if I accidently created this seam myself while editing; that wasn't the case.

 

 Thanks,

  James CW

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch rendering

cwalther
Administrator
James C. Wilson wrote:

> So I've got a potential bug relating to layered patch rendering...
>
> I've got a slide node with a blank, opaque background. Over the
> background there are two patches: One, is a wider-then-background image
> which scrolls back and forth over the background. The second, is a PNG
> with a part in the middle made transparent, so you can see the scrolling
> image behind it. It all works fine, however, I can see a seam, one pixel
> wide, running on the left and right edges of the patch, peeking down
> onto the scrolling image and the opaque background.
>
> This seam is also present in another node where the patch underneath is
> smaller then the background and not scrollling.
>
> If the cause of this is well known I'd appreciate a heads-up. I've
> already checked the PNG to see if I accidently created this seam myself
> while editing; that wasn't the case.

You are probably seeing what is described in the manual, section 2.9
"Patches", as follows:

Subsection "Image":
> For technical reasons (interpolation), the outermost pixels along
> each edge of a patch image should either be identical to the
> corresponding pixels of the background image or fully transparent. In
> other words, the patch image should be one pixel larger on each side
> than absolutely necessary. Otherwise, the patch may appear cut off
> along some edges.

Subsection "Advanced Placement in 3D":

> Width and height of the patch can also be specified in normalized
> units using the nw and nh parameters. Unlike w and h, which give the
> total width and height of the patch, these parameters describe the
> visible width and height. On panoramas and slides, this is one patch
> pixel less than the total width or height because a margin of half a
> pixel is cut off each side of the patch, so that the centers of the
> outermost pixels lie on the edge, to enable a bilinearly interpolated
> patch to blend seamlessly into a bilinearly interpolated background
> image. This is similar to what’s done with the cube faces as
> described under “Making Cubic Panoramas” in section 2.8 “Cubic
> Panoramas”.

You should be able to see this if you make your window so big that you
can clearly see the interpolation of the pixels (at least 3 or 4 times
as big as the original size of the background image).

The upshot of it is that to do what you want, the covering patch must be
strictly wider (not the same width) as what it's supposed to cover. In
the wider-than-background case, that patch must be wider-than-background
too. (Because you're stacking multiple patches rather than just putting
a patch on the background image, replace "background image" in the first
manual quotation with "whatever is behind it".)

If you come to the conclusion that this is not what you're seeing, then
it's entirely possible that we don't handle wider-than-background
patches properly. I don't think I have ever tested those. In that case I
would appreciate a complete reproducing example.

It has recently occurred to me that it could under some circumstances be
useful to be able to display only a (movable) subrectangle of an image
on a patch. That would remove the need for a wider-than-background patch
(and for covering up most of it) in your case too, I think.

  -Christian




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch rendering

James C. Wilson
Ah, thank you. I made the patch two pixels larger and placed it one pixel to the left of the screen.

Thanks,
  James

--- On Wed, 11/30/11, Christian Walther <[hidden email]> wrote:

From: Christian Walther <[hidden email]>
Subject: Re: Patch rendering
To: [hidden email]
Date: Wednesday, November 30, 2011, 3:41 PM

James C. Wilson wrote:

> So I've got a potential bug relating to layered patch rendering...
>
> I've got a slide node with a blank, opaque background. Over the
> background there are two patches: One, is a wider-then-background image
> which scrolls back and forth over the background. The second, is a PNG
> with a part in the middle made transparent, so you can see the scrolling
> image behind it. It all works fine, however, I can see a seam, one pixel
> wide, running on the left and right edges of the patch, peeking down
> onto the scrolling image and the opaque background.
>
> This seam is also present in another node where the patch underneath is
> smaller then the background and not scrollling.
>
> If the cause of this is well known I'd appreciate a heads-up. I've
> already checked the PNG to see if I accidently created this seam myself
> while editing; that wasn't the case.

You are probably seeing what is described in the manual, section 2.9
"Patches", as follows:

Subsection "Image":
> For technical reasons (interpolation), the outermost pixels along
> each edge of a patch image should either be identical to the
> corresponding pixels of the background image or fully transparent. In
> other words, the patch image should be one pixel larger on each side
> than absolutely necessary. Otherwise, the patch may appear cut off
> along some edges.

Subsection "Advanced Placement in 3D":

> Width and height of the patch can also be specified in normalized
> units using the nw and nh parameters. Unlike w and h, which give the
> total width and height of the patch, these parameters describe the
> visible width and height. On panoramas and slides, this is one patch
> pixel less than the total width or height because a margin of half a
> pixel is cut off each side of the patch, so that the centers of the
> outermost pixels lie on the edge, to enable a bilinearly interpolated
> patch to blend seamlessly into a bilinearly interpolated background
> image. This is similar to what’s done with the cube faces as
> described under “Making Cubic Panoramas” in section 2.8 “Cubic
> Panoramas”.

You should be able to see this if you make your window so big that you
can clearly see the interpolation of the pixels (at least 3 or 4 times
as big as the original size of the background image).

The upshot of it is that to do what you want, the covering patch must be
strictly wider (not the same width) as what it's supposed to cover. In
the wider-than-background case, that patch must be wider-than-background
too. (Because you're stacking multiple patches rather than just putting
a patch on the background image, replace "background image" in the first
manual quotation with "whatever is behind it".)

If you come to the conclusion that this is not what you're seeing, then
it's entirely possible that we don't handle wider-than-background
patches properly. I don't think I have ever tested those. In that case I
would appreciate a complete reproducing example.

It has recently occurred to me that it could under some circumstances be
useful to be able to display only a (movable) subrectangle of an image
on a patch. That would remove the need for a wider-than-background patch
(and for covering up most of it) in your case too, I think.

  -Christian



------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Pipmak-Users mailing list
Pipmak-Users@...
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch rendering(a new difficulty)

James C. Wilson

Sorry to come screaming right back, but I've got a similar problem:

  I've got a standard cubic node set up, just the basics: node declaration, a single patch, and that's it. Trouble is, the patch shows a thick white edge at the top and bottom, about 5 pixels thick.

  Initially I had a pipmak.schedule which turned off and on the patch at intervals(to give the effect of a flickering light) but when this problem presented itself I cut the pipmak.schedule out and left the basics, but the problem still persists.

  I have a number of neighboring nodes, all of which have a similar patch, set up the same way, but none of them have this problem.

  Could it be a bug this time? This isn't much info to work with, sorry.

 

 

Thanks,

 James CW



--- On Thu, 12/8/11, James C. Wilson <[hidden email]> wrote:

From: James C. Wilson <[hidden email]>
Subject: Re: Patch rendering
To: "Content creation for the Pipmak Game Engine" <[hidden email]>
Date: Thursday, December 8, 2011, 6:03 PM

Ah, thank you. I made the patch two pixels larger and placed it one pixel to the left of the screen.

Thanks,
  James

--- On Wed, 11/30/11, Christian Walther <[hidden email]> wrote:

From: Christian Walther <[hidden email]>
Subject: Re: Patch rendering
To: [hidden email]
Date: Wednesday, November 30, 2011, 3:41 PM

James C. Wilson wrote:

> So I've got a potential bug relating to layered patch rendering...
>
> I've got a slide node with a blank, opaque background. Over the
> background there are two patches: One, is a wider-then-background image
> which scrolls back and forth over the background. The second, is a PNG
> with a part in the middle made transparent, so you can see the scrolling
> image behind it. It all works fine, however, I can see a seam, one pixel
> wide, running on the left and right edges of the patch, peeking down
> onto the scrolling image and the opaque background.
>
> This seam is also present in another node where the patch underneath is
> smaller then the background and not scrollling.
>
> If the cause of this is well known I'd appreciate a heads-up. I've
> already checked the PNG to see if I accidently created this seam myself
> while editing; that wasn't the case.

You are probably seeing what is described in the manual, section 2.9
"Patches", as follows:

Subsection "Image":
> For technical reasons (interpolation), the outermost pixels along
> each edge of a patch image should either be identical to the
> corresponding pixels of the background image or fully transparent. In
> other words, the patch image should be one pixel larger on each side
> than absolutely necessary. Otherwise, the patch may appear cut off
> along some edges.

Subsection "Advanced Placement in 3D":

> Width and height of the patch can also be specified in normalized
> units using the nw and nh parameters. Unlike w and h, which give the
> total width and height of the patch, these parameters describe the
> visible width and height. On panoramas and slides, this is one patch
> pixel less than the total width or height because a margin of half a
> pixel is cut off each side of the patch, so that the centers of the
> outermost pixels lie on the edge, to enable a bilinearly interpolated
> patch to blend seamlessly into a bilinearly interpolated background
> image. This is similar to what’s done with the cube faces as
> described under “Making Cubic Panoramas” in section 2.8 “Cubic
> Panoramas”.

You should be able to see this if you make your window so big that you
can clearly see the interpolation of the pixels (at least 3 or 4 times
as big as the original size of the background image).

The upshot of it is that to do what you want, the covering patch must be
strictly wider (not the same width) as what it's supposed to cover. In
the wider-than-background case, that patch must be wider-than-background
too. (Because you're stacking multiple patches rather than just putting
a patch on the background image, replace "background image" in the first
manual quotation with "whatever is behind it".)

If you come to the conclusion that this is not what you're seeing, then
it's entirely possible that we don't handle wider-than-background
patches properly. I don't think I have ever tested those. In that case I
would appreciate a complete reproducing example.

It has recently occurred to me that it could under some circumstances be
useful to be able to display only a (movable) subrectangle of an image
on a patch. That would remove the need for a wider-than-background patch
(and for covering up most of it) in your case too, I think.

  -Christian



------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Pipmak-Users mailing list
[hidden email]
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users

-----Inline Attachment Follows-----

------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/

-----Inline Attachment Follows-----

_______________________________________________
Pipmak-Users mailing list
Pipmak-Users@...
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch rendering(a new difficulty)

cwalther
Administrator
James C. Wilson wrote:

> I've got a standard cubic node set up, just the basics: node
> declaration, a single patch, and that's it. Trouble is, the patch shows
> a thick white edge at the top and bottom, about 5pixels thick.
>
> Initially I had a pipmak.schedule which turned off and on the patch at
> intervals(to give the effect of a flickering light) but when this
> problem presented itself I cut the pipmak.schedule out and left the
> basics, but the problem still persists.
>
> I have a number of neighboring nodes, all of which have a similar patch,
> set up the same way, but none of them have this problem.

Can you try to strip down your project to the bare minimum that still
exhibits the problem, and post that somewhere? Preferably not on the
mailing list unless it's smaller than a few dozen kilobytes, but on some
file sharing service or on the bug tracker.

  -Christian



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch rendering(a new difficulty)

James C. Wilson
Sure, uploaded to mediafire.com, login jfcwilson.at.yahoo.com, pass {doormatt94} (Remove braces).

Thanks,
  James


From: Christian Walther <[hidden email]>
To: [hidden email]
Sent: Saturday, December 17, 2011 7:43 AM
Subject: Re: Patch rendering(a new difficulty)

James C. Wilson wrote:

> I've got a standard cubic node set up, just the basics: node
> declaration, a single patch, and that's it. Trouble is, the patch shows
> a thick white edge at the top and bottom, about 5pixels thick.
>
> Initially I had a pipmak.schedule which turned off and on the patch at
> intervals(to give the effect of a flickering light) but when this
> problem presented itself I cut the pipmak.schedule out and left the
> basics, but the problem still persists.
>
> I have a number of neighboring nodes, all of which have a similar patch,
> set up the same way, but none of them have this problem.

Can you try to strip down your project to the bare minimum that still
exhibits the problem, and post that somewhere? Preferably not on the
mailing list unless it's smaller than a few dozen kilobytes, but on some
file sharing service or on the bug tracker.

  -Christian


------------------------------------------------------------------------------
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online. 
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
Pipmak-Users mailing list
[hidden email]
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch rendering(a new difficulty)

cwalther
Administrator
James C. Wilson wrote:
> Sure, uploaded to mediafire.com, login ...

Got it - I'm not sure if giving out your login is the way you're supposed to use Mediafire, but it works... :)

As far as I can see, those white bars are actually part of the patch image (hallLgtOff_left.jpg), so from a quick glance I would say Pipmak is doing nothing wrong.

Looks nice, by the way!

 -Christian

Loading...