Hi Enrico,
On Mon, 2004-09-20 at 03:08, Enrico Borrione wrote:
> Thanks for the answers.
> Obviously every answer contains inside at least another question,
> so...
As long as it's only one that's not too bad. If it's more than one I can
see a problem growing... ;)
> so i'll get down into business:
>
> 1) I was very interested hearing about Functors. It looks like they are
> the facilities i was looking for. Now the question is simple: where can
> i find some paper explaining how to manage the functors? As for now i've
> just found some little examples in the tutorial 09, traversegraph.cpp.
> I am especially interested about the possibility of customizing the
> rendering pipeline for every mesh i display. I meant that when i talked
> about specifying "custom parameters". For example, if i want to use a
> dynamic reflection cubemap, i want to be able to tell in the functor
> that i need additional rendering passes *just* for the interested
> meshes. I don't think i can be clearer than this.
Right now the traversal framework is based on types, not instances.
Therefore you can't specify a functor for a single instance. I don't see
an wasy way around that. The core idea was to add a node multiple times
to the drawtree, controlled by the material. Right now that doesn't
work, because the drawtree directly accesses the Material to get the
State, and there can be only one of those. That's a core argument for
the RenderAction rewrite.
> 2) i'd like to set up a small material library, using GLSL also shaders.
> I planned about building the materials ad hoc over the shader, but for
> doing that i need to pass from the MaterialChunk to the SHLChunkPtr the
> various parameters. Is there a way to shrink those parameters inside the
> material chunks?
> A little example: think that i want a non perfectly reflective material,
> and i want to be able of manipulating the reflectancy of the mesh. In my
> shader i need to have an external parameter, called "reflectivity" that
> tells my card how to mix the reflection with the diffuse color. Usually
> i'd set up a real32 value and then i'd tell OSG something like
> shl->setUniformParameter("reflectivity", reflectivity). Is there a way
> to put that inside the material so i'll have the latter call in the form
> of shl->setUniformParameter("reflectivity", MyCMaterial->reflectivity)?
In general that would mean writing a new Material, which just contains
an SHLChunk that does all the work, just like the MaterialChunk does
most of the work for the SimpleMaterial. How dynamic do you want it to
be? Adding/removing Fields at runtime? That's possible in general, but
the access has to go through the generic interface, which is a little
tedious for applications (but just great for general editors ;).
You could store data as attachments in the Material, but the SHLChunk
wouldn't automatically extract it. In general, what would be the
advantage of not having it as a paremeter of the SHLChunk?
Dirk
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
