pipmak-users

Patch rendering

[James C. W. <jfc...@ya...>]

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

 

Re: Patch rendering

[Christian W. <cwa...@gm...>]

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

Re: Patch rendering

[James C. W. <jfc...@ya...>]

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 <cwa...@gm...> wrote:

From: Christian Walther <cwa...@gm...>
Subject: Re: Patch rendering
To: pip...@li...
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
Pip...@li...
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users

Re: Patch rendering(a new difficulty)

[James C. W. <jfc...@ya...>]

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 <jfc...@ya...> wrote:

From: James C. Wilson <jfc...@ya...>
Subject: Re: Patch rendering
To: "Content creation for the Pipmak Game Engine" <pip...@li...>
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 <cwa...@gm...> wrote:

From: Christian Walther <cwa...@gm...>
Subject: Re: Patch rendering
To: pip...@li...
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
Pip...@li...
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
Pip...@li...
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users

Re: Patch rendering(a new difficulty)

[Christian W. <cwa...@gm...>]

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

Re: Patch rendering(a new difficulty)

[James C. W. <jfc...@ya...>]

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

Thanks,
  James



________________________________
 From: Christian Walther <cwa...@gm...>
To: pip...@li... 
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
Pip...@li...
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users

Re: Patch rendering(a new difficulty)

[Christian W. <cwa...@gm...>]

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