I am trying to export many different objects 3D graphics as JT files and am having some difculty right now, most of the objects export as a JT but frames appear not to.
Can frames only be graphically exported as a S3D file and not as a JT file?
Is there any other objects that cannot be exported as a JT file?
There should be no restriction regarding the object type when it comes to exporting graphics as Jt - the only "restriction" there is that you should be able to enter an object visually in order to export it which excludes Connectors - but in my opinion, exporting a connector (without context) does not make that much sense.
What exactly do you mean with frames appearing not to export?
I am running ._3D.ExportAsJT on multiple items to produce JT files for someone else to use in another program, and as I run it all of the objects produce a JT file as expected but the frames do not.
Looking a bit closer at this, when I use the export function through the interface and not through SimTalk then it works as expected, but this is not ideal as this could be needed again in the future to give people 3D models again.
To help to show what I mean I have created the following project. It does roughly the same as what I am trying to do, but has been made a little more user friendly.
In the 'Exporter' frame use the 'Select Save Location' button and select a folder to save the JT's in, then click the 'Run' button. You will see everything apart from the 'Project.jt' is created in the folder, where 'Project.jt' is the frame itself.
I know that the frame's graphics is in this case very basic, but I would still like to export the default 3D icon for the frame as in reality I am also saving which graphic groups are visible and which are internal so who I am giving them to will be know what is what.
Right now the intention is to create something that can be used on anything to produce the JT files if requested, so I am not sure how complex the frames will become or if they will include anything extra like fences or stairs.
I found out what has happened here.
The frame graphics actually have been saved but due to a bug in the software to the wrong file path.
We will have this fixed in the next maintenance packs.
Thank you for investgating this for me, do you know where it will have been saved to instead or is it unpredictable?
For now I could add in a bit to move the file back to with the others if I know where it is to save me from having to manually export frame graphics seperatly.
Unfortunately, this is not totally predicatable. The string that is used as file location will come from the model somewhere. but there is no general rule regarding which string actually was in use.
If this issue is urgent, I suggest that you contact support so that you might get a hotfix for this.
Otherwise, use the coming maintenance packs.
Quick question which I thought I would ask on here as in this case google is not helping me much.
They wish to store the JT files using Git, but every time I give them a set of exported files it report a differance within Git, does anyone know of a way to ensure that only the JT files of who's graphics have changed is marked as changed within Git, or to mark a object with Plant Sim when its graphics change so I can only export them ones.
As for the original issue, not yet got hold of 13.1 (will do after Christmas) and can then check to see if that solves my issue.
Regardless of whether you changed graphics in an object or not, the exported Jt files will always differ:
So, in Jt files, I guess there is nothing I know of, that might be able to be used for such a comparison.
Now to your second attempt:
This depends on how you change your graphics.
Generally, you can add a user-defined attribute to all the objects you want to manage. This attribute might e.g. be a boolean and be set to, say, false (meaning "unchanged") when the graphic of that object was exported as Jt. If you set the flag then to true whenever you change the graphic of that object, all that is necessary would be done.
Now, unfortunately, there is no general way to observe whether a graphic is being changed. So, if you change the graphic of an object manually, there is nothing you can do, short of setting the flag manually, too, maybe using a user-defined ribbon command or something like that. If you change the graphic with SimTalk, you can of course add code that updates you flag there.
There are some heuristics you could try to check whether the graphic probably is changed or not:
Every 3D object has the method memSize and the bounding box attributes. If you store e.g. the values of those after saving, you could compare them later to previous values and check whether the bounding box values changed (which then definitely means that graphic must have changed in some way, too) and/or the memSize has changed (which can point to a graphic change).
So, a set of rules could look like this: