[Opensg-users] Separate Opaque from translucent objects

[Michael Raab]

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/

[Carsten Neumann]

Hello Michael,

for deferred shading purposes I would like to separate opaque from
translucent objects as I would like to render translucent objects in a
separate forward pass after the deferred shading phase for opaque objects.
If I investigated that correctly, after the call to recurseFromThis() in
DeferredShadingStage::scheduleGBufferPass() the active partition should hold
two filled lists of functors, an opaque and a translucent one.
1.) Copy the current partition (including the mentioned lists)
2.) Clear translucent list from active partion
3.) Clear opaque list in cloned partition
4.) Schedule shading pass
5.) Push cloned partition
6.) Draw the 3 partitions in sequence
- a clone function for partitions
- a push-method using partion pointers
- clear functions for opaque and translucent functor list
Do you see any problems I'm not aware of? Did I miss something?

hmm, IIRC RenderPartitions are allocated off of pools to avoid having
to hit the system memory allocated too often and to allow for reuse of
the storage allocated by their members (e.g. allow reuse of any
std::vectors they contain) and in general requesting a new partition
also sets it up to be rendered.
The lists of opaque and translucent objects are subtrees of the
DrawTree that the partitions build up when traversing the scene. The
nodes of the DrawTree are also allocated from pools (usually quite a
few DrawTreeNodes are needed each frame) and probably don't have
existing API to duplicate them (especially duplicate them on a
different pool).
I guess it's possible to do what you are describing, there are some
details (like the pool allocation) that may need some working around.

Cheers,
Carsten

[Johannes]

Hello Michael and Carsten,

I'm also interested in this topic and would like to ask if you have
found a solution to the problem.

Additionally, do you have any idea if it is possible to use the
DepthPeelingStage in conjunction to the DefferedShadingStage?

Best,
Johannes

Post by Carsten Neumann
Hello Michael,

for deferred shading purposes I would like to separate opaque from
translucent objects as I would like to render translucent objects in a
separate forward pass after the deferred shading phase for opaque objects.
If I investigated that correctly, after the call to recurseFromThis() in
DeferredShadingStage::scheduleGBufferPass() the active partition should hold
two filled lists of functors, an opaque and a translucent one.
1.) Copy the current partition (including the mentioned lists)
2.) Clear translucent list from active partion
3.) Clear opaque list in cloned partition
4.) Schedule shading pass
5.) Push cloned partition
6.) Draw the 3 partitions in sequence
- a clone function for partitions
- a push-method using partion pointers
- clear functions for opaque and translucent functor list
Do you see any problems I'm not aware of? Did I miss something?

hmm, IIRC RenderPartitions are allocated off of pools to avoid having
to hit the system memory allocated too often and to allow for reuse of
the storage allocated by their members (e.g. allow reuse of any
std::vectors they contain) and in general requesting a new partition
also sets it up to be rendered.
The lists of opaque and translucent objects are subtrees of the
DrawTree that the partitions build up when traversing the scene. The
nodes of the DrawTree are also allocated from pools (usually quite a
few DrawTreeNodes are needed each frame) and probably don't have
existing API to duplicate them (especially duplicate them on a
different pool).
I guess it's possible to do what you are describing, there are some
details (like the pool allocation) that may need some working around.
Cheers,
Carsten
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/