Hi Art,
Art Tevs wrote:
Hi J.P.
I think this is the way how to do it. One can even go further and
remove the height and width vectors in the method since we setup them
directly in this method. Hmm, I wonder if this will work correctly:
the screen sized quad is created in the very first call of the unit's
init method. In most cases the input texture is not realized till
this moment, hence texture width/height might be 0 in this case. This
behavior always annoyed me, that texture width/height is 0 before it
get applied to some state. So the correct width and height will only
be setted up in the second frame. However try this, maybe I am wrong.
Yes, in all our code we also explicitly set the width/height to get
around the initial frame problem.
I've run with our code (with rects) and some of the examples and they
appeared to work OK (only using UnitTexture and UnitInOut at the
moment). Maybe you can just double check on your side, I'm not so
familiar with all the examples. I also saw code in
UnitTexture::setTexture to explicitly set the texture size by using the
image of the texture, so maybe my test case does not trigger any 0
initial size problems.
rgds
jp
cheers, art
J.P. Delport wrote:
Hi Art,
attached find my latest attempt. I'll continue with rect support in
other units/plugin/etc after you give go-ahead.
rgds jp
J.P. Delport wrote:
Hi Art,
Art Tevs wrote:
Yes, it is the only one place, where the quad is created. The
right place would be to add the multiple texture coordinates
there. Yes, accesing mInputTex (or directly through
getInputTextureMap() method) should be fine there. However make
sure that you do this after Unit::init() call or actually after
Unit::setupInputsFromParents() call. This is because the
mInputTex is first correctly setted up just right after those
calls.
OK, I will start with this.
Is it necessary to create coords per input texture, or would
it be OK to always just generate two sets: one for normalised
range and one for rects? This assumes that all input
rectangles to a unit has the same size?
No, I would create coords for every input texture, even if they
are just the same in all cases. This would allow us to
introduce later maybe some kind of TextureCoordinatesMatrix,
which can be used to change the uv-coordinates of the screen
sized quad for different input units. Not sure how one can use
it, but why not (maybe for some special effects) ;)
OK, will make coords per input. I will start with 0 params to
createTexturedQuadDrawable as this is how it is called in all
current cases.
We should still then think of how the user can specify
coordinates manually (maybe extra map to accompany
mInputTextures?) or some transform like you said.
rgds jp
cheers, art
-- This message is subject to the CSIR's copyright terms and
conditions, e-mail legal notice, and implemented Open Document
Format (ODF) standard. The full disclaimer details can be found at
http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean. MailScanner thanks
Transtec Computers for their support.
_______________________________________________ osg-users mailing
list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
------------------ Post generated by Mail2Forum
------------------ Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=20875#20875
_______________________________________________ osg-users mailing
list [email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
