From: Christoph F. <c.f...@gm...> - 2013-09-25 11:30:11
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi,</div> <div> </div> <div>thanks a lot for looking into it.</div> <div>Just a question on the side:</div> <div>Is it correct Collada to have ids, which start with an underscore,</div> <div>e.g., "<visual_scene id="_entity_balken01" name="_entity_balken01">" ?</div> <div>Because in the combination</div> <div> "<scene><br/> <instance_visual_scene url="#_entity_balken01"></instance_visual_scene><br/> </scene>"</div> <div>it does not find the scene root node ..</div> <div> </div> <div>Thanks,</div> <div>Christoph</div> <div> </div> <div> </div> <div>On 25.09.2013 11:14, Gerrit Voß wrote: <blockquote cite="mid:138...@fe..." type="cite"> <pre wrap="">Hi, On Mon, 2013-09-23 at 18:44 -0500, Carsten Neumann wrote: </pre> <blockquote style="color: rgb(0, 0, 0);" type="cite"> <pre wrap=""><span class="moz-txt-citetags">> </span> Hello Christoph, <span class="moz-txt-citetags">> </span> <span class="moz-txt-citetags">> </span>On 09/23/2013 07:37 AM, "Christoph Fünfzig" wrote: </pre> <blockquote style="color: rgb(0, 0, 0);" type="cite"> <pre wrap=""><span class="moz-txt-citetags">> > </span>I have a crash with rendering a scene loaded as Collada (OpenSG 2.0, Win x64). <span class="moz-txt-citetags">> > </span>In OSGGeoImmediatePumpGroup.cpp: <span class="moz-txt-citetags">> > </span> void pumpMultiAttrib(PumpClassicInfo &info, UInt16 slot, GLenum attrib, UInt32 vertIdx) <span class="moz-txt-citetags">> > </span>for slot==9 all indices "info.attribIndex [slot]->getValue<UInt32>(vertIdx)" are invalid. <span class="moz-txt-citetags">> ></span> <span class="moz-txt-citetags">> > </span>I used no graph-ops at all during loading: OSG::SceneFileHandler::the()->setDefaultGraphOp(NULL); <span class="moz-txt-citetags">> > </span>Please see the example scene <span class="moz-txt-citetags">> > </span><a class="moz-txt-link-freetext" href="https://www.dropbox.com/s/ytyzymw07rmewqa/_entity_balken01.dae" moz-do-not-send="true">https://www.dropbox.com/s/ytyzymw07rmewqa/_entity_balken01.dae</a> <span class="moz-txt-citetags">> > </span>to reproduce the problem! </pre> </blockquote> <pre wrap=""><span class="moz-txt-citetags">> </span> <span class="moz-txt-citetags">> </span>thanks, I'm looking into it. Looks like the collada loader produces an <span class="moz-txt-citetags">> </span>invalid geometry (default graph ops crash as well - specifically the <span class="moz-txt-citetags">> </span>striper). More precisely the index for TexCoords1 is broken, it has a <span class="moz-txt-citetags">> </span>bunch of leading UInt32(-1) values, before (what looks to be) correct <span class="moz-txt-citetags">> </span>data starts. Haven't found the source of it yet. </pre> </blockquote> <pre wrap="">the source of the -1 is in the dae file. Problem is the dom code returns these arrays as domListOfUInt. One thing one has to do is check if an index contains -1 (readTriangles does this) and than discard it. But there is a bug, the comparison uses the wrong type UInt32, it should be domUint as otherwise the comparison fails on 64bit system. If you haven't got one I can quickly generate the patch. kind regards gerrit </pre> </blockquote> </div></div></body></html> |
From: Gerrit V. <vo...@vo...> - 2013-09-26 06:10:46
|
Hi, On Wed, 2013-09-25 at 13:30 +0200, "Christoph Fünfzig" wrote: > Hi, > > thanks a lot for looking into it. > Just a question on the side: > Is it correct Collada to have ids, which start with an underscore, > e.g., "<visual_scene id="_entity_balken01" name="_entity_balken01">" ? > Because in the combination > "<scene> > <instance_visual_scene > url="#_entity_balken01"></instance_visual_scene> > </scene>" > it does not find the scene root node .. to me the reason looks more like a name clash as the root node in your scene has the same id : <node name="_entity_balken01" id="_entity_balken01" sid="_entity_balken01"> Using _entity_balken01 currently crashes so I look into this, but if I use _x_entity_balken01 instead it loads the scene as expected. kind regards gerrit |
From: Christoph F. <c.f...@gm...> - 2013-09-26 10:22:47
|
Hi Gerrit, On 26.09.2013 08:10, Gerrit Voß wrote: > Hi, > > On Wed, 2013-09-25 at 13:30 +0200, "Christoph Fünfzig" wrote: >> Hi, >> >> thanks a lot for looking into it. >> Just a question on the side: >> Is it correct Collada to have ids, which start with an underscore, >> e.g., "<visual_scene id="_entity_balken01" name="_entity_balken01">" ? >> Because in the combination >> "<scene> >> <instance_visual_scene >> url="#_entity_balken01"></instance_visual_scene> >> </scene>" >> it does not find the scene root node .. > to me the reason looks more like a name clash as the root node in > your scene has the same id : > > <node name="_entity_balken01" id="_entity_balken01" > sid="_entity_balken01"> > > Using _entity_balken01 currently crashes so I look into this, but if I > use _x_entity_balken01 instead it loads the scene as expected. > > yes, "node id" and "visual_scene id" are the same in this case. <visual_scene id="_entity_balken01" name="_entity_balken01"> <node name="_entity_balken01" id="_entity_balken01" ..> It came to me like this, as the result of the DAE/FBX exporter from exporting a node named "_entity_balken01", into a file named "_entity_balken01.dae" ;-) So really a special case, but to please Maya .. Thanks again, Christoph |
From: Gerrit V. <vo...@vo...> - 2013-10-03 02:16:25
|
Hi, On Thu, 2013-09-26 at 12:22 +0200, Christoph Fünfzig wrote: > Hi Gerrit, > > On 26.09.2013 08:10, Gerrit Voß wrote: > > Hi, > > > > On Wed, 2013-09-25 at 13:30 +0200, "Christoph Fünfzig" wrote: > >> Hi, > >> > >> thanks a lot for looking into it. > >> Just a question on the side: > >> Is it correct Collada to have ids, which start with an underscore, > >> e.g., "<visual_scene id="_entity_balken01" name="_entity_balken01">" ? > >> Because in the combination > >> "<scene> > >> <instance_visual_scene > >> url="#_entity_balken01"></instance_visual_scene> > >> </scene>" > >> it does not find the scene root node .. > > to me the reason looks more like a name clash as the root node in > > your scene has the same id : > > > > <node name="_entity_balken01" id="_entity_balken01" > > sid="_entity_balken01"> > > > > Using _entity_balken01 currently crashes so I look into this, but if I > > use _x_entity_balken01 instead it loads the scene as expected. > > > > > yes, "node id" and "visual_scene id" are the same in this case. > <visual_scene id="_entity_balken01" name="_entity_balken01"> > <node name="_entity_balken01" id="_entity_balken01" ..> > > It came to me like this, as the result of the DAE/FBX exporter from > exporting a node named "_entity_balken01", > into a file named "_entity_balken01.dae" ;-) > So really a special case, but to please Maya .. hmm, does the scene name depend on the file name or the node name ?. I'll have to check if one can resolve it by doing local library searches if the internal collada lookup fails. In your case it finds the node first and fails on the following downcast to scene. For the general loading problem I committed a fixed. Now the loader checks for invalid indices (have to check all for primitive types though) and removes any index with -1 in it. As this leaves you without any texture coordinates I added one option to the collada loader (tryMergeInvalidIndices). In this case the loader checks if it can merge multiple invalid indices into a valid one if the -1 blocks do not overlap, e.g. for something like: index1: 1 2 3 4 -1 -1 -1 5 6 7 8 index2: -1 -1 -1 -1 11 12 13 -1 -1 -1 -1 the loader will merge: index1: 1 2 3 4 11 12 13 5 6 7 8 index2: reuse index1 As this is the case for your file you at least are able to get a geometry with texture coordinates out of the loader. kind regards gerrit |