Hi Daniel,
On Tue, 2005-11-01 at 17:49 -0800, Daniel Sperka wrote:
> Hi -
>
> I am working on an application where the user navigates across a plane.
> The surface of the plane is a grid of square regions. Each square
> requires a unique texture. The textures are generated prior to the start
> of rendering.
>
> I have several questions regarding implementation. I've done quite a bit
> of searching in the archives but haven't come across a solution suggestion.
>
> 1. In any given frame there may be several (<10) of the squares visible.
> Prior to rendering the frame I determine which squares are required. I'd
> like to tie this operation to changes in the camera beacon
> transformation. Where is the best place to do this?
the best place would be a callback on changed(), but we don't have that
currently.
> My first thought is to subclass (via fcdEdit) the Transform and to use
> its changed() method. Is this a good idea? My subclass will need to have
> a NodePtr, and it will need to add/sub children to/from it. I'm worried
> about changes I make to the scenegraph in this method. Any nodes which I
> modify will be _below_ the Transform (camera beacon node) in the graph.
> Can I modify the node itself (that is, the node which owns the
> transform) by adding/subbing children from inside the changed() method?
Hm, no, that won't work. While a ChangeList is applied (which is when
changed() is called), it is set to read-only.
> If I don't use changed, is there another method which is preferable?
Do you have to hide it in the scenegraph? That makes sense when you want
to be able to combine it with other applications, but if you're doing
this more a specific app, just doing it in your own program generally
simplifies things. You could just use the TravMask to selectively turn
nodes on and off before calling win->render() (or ssm->redraw()).
You could also write a simple NodeCore for your operations. Just do your
calculation in the render() method, and only add the children that you
want added to the traversal list (see Switch or LOD for an example).
> It seems that materials (and hence textures) must be 1:1 with a
> geometry. This is why I've been assuming that each square must have its
> own geometry and material.
That's right. But given that you don't have a lot of them I don't expect
that to be a problem.
> 2. For each animation sequence I will need to traverse hundreds of the
> rectangular grids. Thus, I'll be using hundreds of unique textures. The
> textures cannot be repeated. What is the most efficient (fastest) way to
> accomplish this? I can afford to pay a cost up front (pre-loading
> textures in some way), but during the rendering of frames I must have
> frame-by-frame control, so I have to avoid (computationally) costly
> operations during animation.
Do you have enough texture memory to store all of them (maybe
compressed)? If yes, you can just call win->validateAllGLObjects(),
which will upload everything (textures, geometry, shaders) to the
graphics card.
If you don't have enough memory you might get a hickup when a new
texture is moved to the card. Preventing that is non-trivial, as you'd
have to know beforehand which textures will be used later and upload
them slowly before they're used.
Hope it helps
Dirk
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
