>>> this hack was necessary to load old 1.x osb files. In 1.x the
>>> MaterialChunk has a internal field, not sure about 2.0 but I think there
>>> is no "real" internal field anymore.
>>
>> hm, I just looked through CVS history but could not find such a field in
>> OSGMaterialChunkBase.h, but I guess I'll just leave the hack in.
>
> yes this field exists in every StateChunk I think it comes from the
> Attachment class.
ok.
>> Something different on NFIO:
>> There is the postProcess operation that seems to do some conversions
>>> >from old formats and apparently is allowed to delete FCs along the way.
>> Now, my question is: shouldn't this happen *before* calling
>> chargeFieldPtr and update the id map correspondingly ?
>
> well I'm not sure if this works but right now it works fine and it is
> safe because I use the fieldcontainer id's and not the pointers. There
> is a comment in OSGNFIOBase.cpp line 279
My problem is that I think I can construct an example that easily breaks
with the current scheme, unless I miss something:
Lets have a file with two nodes that share a core. Lets say loading
these gives us a "file id" to "system id" map for the pointers like this:
file id system id
node1 3 13
node2 4 14
core 5 15
Charging the pointers gives the expected layout:
node1 node2
\ /
\ /
core
Suppose the postProcess for core replaces it with a new container, how
are the pointers in node1, node2 fixed to point to the new instance ?
ATM only NFIOGeometry seems to do something like this by fixing the
interleaved indices, but I believe for a file with 2 geometries that
shared interleaved indices it would at least destroy the sharing -- or
maybe I don't really get it ?
Thanks,
Carsten
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
