Hello Michael,
On 05/30/2013 04:29 AM, Michael Raab wrote:
> 1.)
> We have the need to update some shader variables frequently, e.g. those
> who depend on our system time.
> With 1.8 I checked each frame for newly created SHLChunks und there
> checked for certain uniform variable names using method
> hasUniformVariables().
> Once found I updated the variables each frame..
> How can this done in 2.0, may be there is a smarter way...
I think you could have a ShaderVariableChunk in a ChunkOverideGroup on
the root (or near it) and IIRC it gets merged with a ShaderVariableChunk
on a material further down the tree. Gerrit, could you confirm if that
is how the shaders get combined? Thanks!
> What I recently saw were OSGProceduralVariables. Can they be used for
> this purpose? Can all my shader programs share one variable, e.g. for
> current system time?
I don't think there are user defined procedural variables, there are
uniforms with "magic" names that OpenSG supplies and updates as needed
(e.g. various matrices) - see
Source/System/State/Shader/Variables/OSGShaderVariableOSG.{cpp,h} for a
list.
> What happens if I write an OSGProceduralVariable to osb und reload it?
The pre-defined ones should be restored. I would expect user-defined
ones to be lost (if we had them), since it's not clear how to
save/restore a function pointer ;) - that means they would also be not
transmitted across a cluster.
> 2.) Definitions: What is
> - a stage?
basically a NodeCore that redirects the rendering of the tree below it
into an FBO. A stage can also perform multiple passes (into different
targets if needed) over the tree below it.
> - a partition?
This is the backend (internal) representation created by a stage, you
could think of it as a render pass.
> - draw mode: SequentialPartitionDraw vs. ParallelPartitionDraw?
In ParallelPartitionDraw completed partitions are being drawn
concurrently with other partitions that are still being filled. It
basically makes drawing (in the sense of issuing OpenGL drawing
commands) parallel to tree traversal/frustum culling. Gerrit will have
to comment on how complete/stable the parallel mode is.
> - a view area?
Hmm, I think this like a viewport (pixel position + width and height)
without the other stuff an OpenSG viewport has (root, foregrounds,
background, etc).
> 3.) commitchanges()
> Could you please explain shortly what this exactly does? Is this
> relevant for multi-threaded/cluster applications only?
commitChanges() causes the changed() function of all FieldContainers
that have had any field written (since the last time commitChanges ran)
to be executed. This used to happen from the endEditCP() call in 1.x,
but since these are gone, the commitChanges() call is needed to run the
necessary updates. It should be called at least once a frame, or before
you access lazily computed information (mostly bounding volumes and
their dirty flags).
Cheers,
Carsten
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
