This time I'm having troubles with JT2Go and a file with geometry.
JT2Go won't display it. Only the structure is displayed correctly. It also displays that the file has PMIs, which it definitely does not have.
I suspect our exporter to create something incorrect. Can someone confirm this or even tell me what is wrong with the file.
I can load the geometry correctly from the file with our importer.
Solved! Go to Solution.
The clip.zip file is the same part that you sent to us before. Did you re-export this differently? In your last post, the geometry was visible, but it did not show up unless you changed the size culling setting. Is this the same issue?
Something is wrong with the JT file. When I opened the JT file in NX, there is warning about the "missing length units"
Checked the JT file in JT2GO(11.2.3) and TC Vis Pro 11.2, there was no geometry visible in UI at all. Irrespective of visibility of the geometry, I had exported the JT file from TC Vis and opened in NX again and there I can see the geometry of the JT.
Strange thing is when same JT (exported from TC Vis) is opened in JT2GO, the geometry is not visible.
Thanks for the efforts! I'd like to find out, what exactly is wrong with the file so I can fix it.
I'm using JT2Go 184.108.40.20670130.01 and I can confirm your described behaviour.
However the clip in the Vis_Export_Clip directory seems to be missing the part(?).
Vis_Export_Clip.jt has it's part.
The PMI-Flag is gone and the fileformat changed from V9.5 to V10 in both your exports.
Could the "missing length units" prevent JT2Go to display the brep correctly?
So NX can display the geometry if TC Vis re-exports it?
Can NX display my uploaded original file?
The last time we went through this, you indicated the following:
I'm using the Techsoft3D Exporter "Exchange".
However I'm not directly converting. Instead, I parse the files and translate them into my internal visualization format. I then export the tessellation from my internal format to JT.
I will forward this information to the exchange-team to find out what i'm doing wrong.
Can you check with this team again to see if they can help you determine what is wrong with your export.
Thanks for the reply!
Like in my first issue, I already asked the Team from Techsoft3D for help, but since they are able to import their own written format, they won't put much effort in resolving problems with other software. So that is most probably a deadend.
However if I can pinpoint the issue, they might be able to fix it without much effort - and this is increasing the chance that they will fix it at all.
I can also understand if you would not want to support any software other than your own.
I'd appreciate your (and anybody elses) help though.
And reading a
semi-valid jt file should also be in interest for the JT2Go-team
First of all, thank you for the questions here, which highlight some questions I'll bet other folks have as well. Let me get right to it.
I have examined both of the files that are the subject of this discussion forum to determine what's up. I know it can be frustrating when something doesn't work the way one thinks it should. My group and I are the original authors of the JT file format, and have been maintaining and developing it since its original inception in 1996.
The issue with clip.zip is that it was written with an area of 0 on the TriStripSet nodes. The area field must be correct in the JT file, otherwise it is invalid, and will likely not display. This area field is not optional, and not arbitrary. It must contain a reasonable approximation to the model-coordinate space area of the TriStripSet, otherwise it's a case of "garbage-in, garbage-out."
The issue with the second file is that it contains no tessellated geometry at all. This is not a supported scene graph construction, as documented in the "Best Practices" chaper of the JT Specification, in the section titled "LSG Part Structure". The first purpose of the JT file is to support fast and efficient visualization, and that can't be done with only an XTBrep present. Tessellating a Brep to polygons is a very time-consuming process when done correctly, and not something that any application is going to want to do (particular on large assemblies) every time it loads a JT file.
The purpose of the JT, and the specification itself, is to make JT as open an widely useful as possible, both in our own products and in 3rd party products and workflows. But that can only happen if the conventions and rules set up in the Specification are met. Concretely, this means writing a valid area and tessellation to to every JT file.
Siemens PLM / DirectModel
Thanks a lot for the insight!
The first issue is already in a work-in-progress state.
The explanation for the second issue is also comprehensible for me.
We can work with that.
Thank you very much for sharing this information.
Have a great day!