Hello Michael,
On 01/24/2012 02:55 PM, Michael Raab wrote:
> Am 24.01.2012 um 00:09 schrieb Carsten Neumann<carsten_neum...@gmx.net>:
>> On 01/23/2012 07:47 AM, Michael Raab wrote:
>>> Node
>>> - MatGroup1
>>> - Geo1
>>> - MatGroup2
>>> - Geo2
>>> Node
>>> - MatGroup3
>>> - Geo3
>>> - Geo4
>>>
>>> Geo1 and Geo2 are rendered correctly, Geo3 and Geo4 are rendered with
>>> wrong material.
>> which material is used for Geo3, Geo4? One from MatGroup1, MatGroup2 or
>> something different entirely? Is the used material for Geo3, Geo4 view
>> dependent?
>
> Geo3 and Geo4 have a material (I'll call it mat3) that is completely
> different from the Materials that are used for Geo1 and Geo2.
just to be sure: the material of Geo3, Geo4 should not matter, since
they are below MatGroup3 only the material of MatGroup3 should be used
for them.
> Material properties seem to have no real Impact. But if I switch lightning on
> for mat3 the geos turn completely white if it turns off it seems to be not
> lit but gets the diffuse color of mat2... So it seems that the lit property
> was respected whereas other properties are completely ignored... I have no
> clue...
hmm, just a thought: are you running any GraphOps as part of your
loading (perhaps the defaults)? Anything like SharePtr-, Merge-, or
MaterialMergeGraphOp that could possibly be sharing objects that are not
meant to be shared are suspect...
I don't have a precise idea how that could cause the effect you are
seeing, but it could be a hint to either getting a smaller test case or
locating the problem.
>>> A huge problem is that this happens only in a large
>>> context, that means if I load only these two node structures everything
>>> seems to be fine. So producing some small and fancy example is currently
>>> unfortunately not an option. :-(
>>> I do not have any ideas where to start the search for the part that is
>>> broken inside the render tree. Does someone has any ideas how to proceed?
>>
>> Hmm, I think the first thing to isolate should be if the error happens
>> when constructing the DrawTree or when processing it: what material is
>> used in MaterialDrawable::renderActionHandler() when calling dropFunctor()?
>
> I'll try to find out. But could you give me a rough idea at which stages the
> DrawTree is created, when the actual rendering starts and which the main
> procedures are? That is one of the few things I haven't completely understood
> within OpenSg....
The DrawTree is built while the scene is traversed by RenderAction. The
callbacks on the various NodeCore types either affect which children to
visit or build up the DrawTree (by calling e.g.
RenderAction::dropFunctor(), RA::dropLight()). The draw tree implements
the state sorting by grouping objects with the same material into the
same sub-tree.
Actual rendering is only done afterwards from RenderAction::stop() by
traversing the DrawTree and calling the functors stored in the leaves.
For Geometry the RenderAction callback during traversal is
MaterialDrawable::renderActionHandler(), which drops a functor pointing
to Geometry::drawPrimitives() into the DrawTree, together with a pointer
to the material to use. When going through the DrawTree the state
associated with that material is activated and the functor called.
Cheers,
Carsten
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
