Hello Andreas,
Andreas Halm wrote:
> Thats what I do exactly and I keep getting
> OpenSG FATAL: ShaderProgramChunk::deactivate
hm, strange. This means somehow a ShaderProgramChunk actually gets to
the backend. At the point where the activate/deactivate calls happen
they should have been replaced by ShaderExecutableChunks.
> Although the rendering looks correct. This doesn't happen if I create a
> ShaderExecutableChunk myself und use activate/deactivate on it. That would
> be an alternative but if I understood correctly that class should normally
> not be used by me?
no, you should not create those yourself, they are used by the backend
for fully linked programs.
> I am using a ChunkMaterial and my render setup is:
>
> func = boost::bind(&Residue::draw,this,_1);
> pPrimeMat = material->finalize(a->getRenderProperties());
> State *st = pPrimeMat->getState(0);
> a->dropFunctor(func,st,pPrimeMat->getSortKey() + 0);
>
> which I shamelessly copied from OSGMaterialDrawable ;-)
hm, in that case I don't understand how the ShaderProgramChunk gets through.
> So actually I have two working setups, one is throwing errors which I don't
> understand and I should not use the other one.
>
> Additionally, the state switch occurs multiple times per frame, which would
> not be needed. I guess it is because the finalize call creates a new
> primematerial every time it is called, so there is no easy way to compare
> the last used state with the current one. Is there an easy way around this?
> Should I save the prime material for reuse until something changes? Just
> trying to minimize unnecessary state changes ...
hard to say what is happening, but if this is the way MaterialDrawable
handles it I'd hope it is not totally off target.
What exactly is "the state switch" you are referring to, i.e. what state
is being switched from what to what?
Cheers,
Carsten
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
