Hi Richard,
This is roughly the way I tackled the task with PrecipitationEffect,
although I don't go via extension structure, refactoring things to
avoid the extension function looks ups would help speed.
Another possible speed up would be to look into implementing the
instancing extension as for your particular task it is probably ideal.
Robert.
On Mon, Aug 18, 2008 at 8:24 AM, Schmidt, Richard
<[EMAIL PROTECTED]> wrote:
> Hi again,
>
> i tried using vertex attributes like this:
>
> void PartialTreesDrawable::drawImplementation(osg::RenderInfo&
> renderInfo) const {
> const osg::Drawable::Extensions* extensions =
> osg::Geometry::getExtensions(renderInfo.getContextID(),true);
>
> if ( extensions && _drawable.valid() && _speedTrees.valid() &&
> !_speedTrees->_trees.empty() ) {
> Speedtrees::Trees& trees = _speedTrees->_trees;
> Speedtrees::Trees::iterator it;
>
> for ( it = trees.begin(); it != trees.end(); ++it ) {
> extensions->glMultiTexCoord3fv(GL_TEXTURE0+4,
> it->_position.ptr() );
> extensions->glMultiTexCoord4fv(GL_TEXTURE0+5,
> it->_rotation.ptr() );
> extensions->glMultiTexCoord1f(GL_TEXTURE0+6, it->_scale );
> extensions->glMultiTexCoord1f(GL_TEXTURE0+7, it->_windOffset );
> // draw the tree
> _drawable->drawImplementation( renderInfo );
> }
>
> }
> }
>
>
>
> However it seems to run slower than the implementation using uniforms.
> Any ideas? Is this the recommend way for uploading variables to the
> shader?
>
> Richard
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Robert
> Osfield
> Sent: Friday, August 15, 2008 1:40 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Confused about Uniforms and StateSets.
>
> HI Richard,
>
> On Fri, Aug 15, 2008 at 12:06 PM, Schmidt, Richard
> <[EMAIL PROTECTED]> wrote:
>>>As a general rule it's best to minimize the number of StateSet and
>>>associated StateAttribute/Uniform/Mode changes, both form the OSG's
>>>CPU cost, as well as the cost down on the GPU with stalling the
>>>graphics pipeline with state changes. Uniforms in particular can be a
>>>very expensive state change as some drivers treat uniforms as
>>>constants and recompile or relink the shader program.
>>
>> I doubt that this is reality.
>
> Well perhaps you need to do some reading up on uniforms and GLSL and
> the optimizations that drivers are allowed to do and do undertake.
>
>> In particular Speedtree uploads the
>> treeposition (and other per instance parameters) via a uniform and is
>> known as a fast tree rendering api.
>
> This suggests that that uniforms they are varying aren't ones that can
> be easily optimized away, or that they are missing a trick to
> optimizing the code further.
>
> For commonly varying values you should always use vertex attributes,
> the graphics hardware and drivers are all optimized for handling
> varying vertex attributes. Uniforms are very different from vertex
> attributes, uniforms are akin to the parameters you set in glLight,
> glTexGen etc, they are a state change.
>
>> It would be nice if uniforms do not affect stateset sorting or require
>> statestets at all. I don't know if that fits into the current
>> architecture, however osg should provide a mechanism for updating a
>> single uniform many times in the same frame.
>
> The mechanism is via osg::StateSet, it fits with the granularity of
> state that OpenGL and the hardware suits, so it's the right place for
> them. However, the CPU cost is higher than I'd like, the loose
> coupling between uniforms and programs makes the OSG pretty flexible,
> but wiring up uniforms to they current active program is relatively
> expensive - perhaps this could be improved, but it won't change the
> fact that uniforms aren't meant to be treated like vertex attributes
> and changed often.
>
> Robert.
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
> g
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
