<div dir="auto">This has been recorded @ sourceforge, I will hopefully get response there. Sourceforge is working for me again.</div><div dir="auto"><br></div><div dir="auto">What’s the difference between a sour geforce and a source forge?</div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jul 17, 2025 at 6:16 AM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Summary:<div><br></div><div>Get correct skin/skinCoord Coordinate node DEF/USE order for BoxMan4.java output output [sic]. And test with Michalis' tools.<br><div><br></div><div><a href="https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/BoxMan4Index.html" target="_blank">https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/BoxMan4Index.html</a><br><br>Running the Java on that page produces these two files:<br><br>Skin/BoxMan4_JavaExport.x3d<br>Skin/BoxMan4_JavaExport.x3dv<br><br>Neither of them pass castle-model-converter or castle-model-viewer.<br><br>Please use the X3DJSAIL CommandLine validate to see some of the warnings, but the one's I'm interested in and want to debug are the errors that castle-model-converter and castle-model-viewer produce. If I pass those, then I have a chance of rendering.<br><br>Compare with the original BoxMan4 which renders fine in castle-model-converter and sunrize: <a href="https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/BoxMan4.x3d" target="_blank">https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/BoxMan4.x3d</a><br><br>So, I would say that either 1) X3dToJava.xslt in X3DJSAIL produces bad Java (I think it's okay, but not having USE or DEF in the Java might be an option), or X3DJSAIL is producing/exporting bad X3D and X3DV (via the BoxMan4.java program, due to Coordinate node orderiing with DEF/USE).<br><br>I am attaching a zip with a log that shows my experiments. I did modify the Java slightly, but you can compare with the web page. Note that most of the errors are info, with a couple of warnings.<br><br>The primary reason, AFAICT in X3D and X3DV exports, for the errors, is USE before DEF in the Humanoid, particularly Coordinate USE/DEF (skinCoord and skin Coordinates). I encourage you to use xsl:sort in the X3DJSAIL creation stylesheet, or some way to make sure that DEF comes before USE. I think the field order one must worry about is to <b>make your choice on skin vs skinCoord field ordering on output from Java. </b> My goal would be to follow the order of the .x3d in the archive.<br><br>Please choose which order you like and make sure your BoxMan4.java output views, just like the original BoxMan4.x3d. I suggest using the same order of fields as appear in your X3D input to create Java.<br><br>Sorry it took so long to explain this. I don't want to maintain my own copy of X3DJSAIL. I used a copy downloaded from the X3DJSAIL website.<div><br></div><div>The zip contains a log file from running Castle/javac/java and .x3dv and .x3d files.</div><div><br></div><div>As I start relying more and more on JRuby, Clojure, GraalJS, Java, GraalPy, this is becoming more important. I may have to take over X3DJSAIL development. Me stylesheets?</div><div><br></div><div>For example, in the Java code, this appears:</div><div><br></div><div><b>.setSkinCoord(new Coordinate("SKINCOORD")</b>.setPoint(getSKINCOORD_4_120_point())) .addSkin(new Group()<br> .addChild(new Shape("TrouserSkin") .setAppearance(new Appearance() .setMaterial(new Material().setDiffuseColor(0.0,0.0,1.0).setTransparency(0.5))) .addComments(" # 0: sacrum (8) # 1: l_hip joint (8) # 2: r_hip joint (8) # 3: l_thigh (48) # 4: l_knee joint (8) # 5: l_calf (40) # 10: r_thigh (48) # 11: r_knee joint (8) # 12: r_calf (40) ")<br> .setGeometry(new IndexedFaceSet().setCoordIndex(getIndexedFaceSet_6_123_coordIndex())<br> <b>.setCoord(new Coordinate().setUSE("SKINCOORD"))))</b></div><div><br></div><div><br></div><div>Which appears like The DEF is before the USE. But in reality, searching for SKINCOORD mentions in the Skin/BoxMan4_JavaExport.x3d reveals USE before DEF.</div><div><br></div><div> <Coordinate USE='SKINCOORD'/><br> <Coordinate USE='SKINCOORD'/><br> <Coordinate USE='SKINCOORD'/><br> <Coordinate USE='SKINCOORD'/><br> <Coordinate USE='SKINCOORD'/><br> <Coordinate DEF='SKINCOORD' point='</div><div><br></div><div>If it's too hard to reorder the skin/skinCoord fields, maybe start using references instead of setUSE?</div><div><br></div><div>Maybe we should just remove any setDEF()/setUSE() in Java? That would be interesting! I think we did something similar for ProtoInstances.</div></div></div></div><div dir="ltr"><div><div><div><br>John</div></div></div></div>
</blockquote></div></div>