Jump to content

What model format is PTC, and how can I import my own models?


Recommended Posts

I noticed that some of the controls actually use 3D models. For instance, if you turn on debug keys (LVdebugKeys=True) and press Ctrl+Shift+D, then Ctrl+Shift+_, it toggles wireframe drawing. This affects the appearance of many of the Modern controls. In addition, if you go to your LabVIEW installation directory, and open the "resource" folder, there's a folder in there called "models", which contains several files with names corresponding to different types of controls. Six of them are in 3DS format, and are in fact valid models that can be loaded in a 3D modeling program. The other 36, however, are in some format with the extension ".ptc", and a quick Google search doesn't turn up anything about that model format. So what model format is that? (At least it's not the only model format it supports.) And more importantly, how can I get LabVIEW to load a custom model for a custom control?

 

EDIT: I edited slided.3ds in Blender and the changes were visible on the Boolean slide switch controls.

Edited by flarn2006
Link to comment

Okay, I think I figured something out. The first eight bytes are 32-bit integers. I'm pretty sure the first corresponds to the number of "parts" the model has, but the second I'm unsure of. After that are coordinates of points as single-precision (32-bit) floats, in the order X, Y, Z, X, Y, Z, …. The aforementioned "parts" mentioned before are separated by "FF FF FF FF". As for what determines which points are connected to which, I'm not sure. That would likely use integer values, but there aren't any non-float values other than those two integers at the beginning and the FFFFFFFF that separates each part. I don't think the order in which the points are listed affects it.

However, the apparent lack of any information related to which vertices are connected made the term "point cloud" come to mind. And then I realized: perhaps that's what PTC stands for.

One more thing: it seems the models' filenames are hard-coded into LabVIEW.exe. Which means it wouldn't be surprising if it can't load model files that it's not already programmed to load. However, I did find this humorous string, presumably used for debugging: "This model doesn't know how to see it's [sic] shadow. Two more weeks of winter." :)

But seriously, LabVIEW's support for custom control graphics is just terrible. It's almost a joke: the only supported formats in which you can load in images (as opposed to only being able to use specific hard-coded images built in to LabVIEW) are all non-scalable raster formats. There is one exception, but that exception is Windows metafiles, and that format just sucks. And if they're going to program in 3D support, why not enable importing of models as well?

EDIT: Apparently it also supports PICT images, which also support vector graphics. But that's yet another obsolete format that nobody uses. And some format with a ".aaa" extension, which I know nothing about. I only suspect that because ".pct" and ".aaa" are found as strings near ".wmf" in LabVIEW.exe.

Edited by flarn2006
  • Like 1
Link to comment

We've been asking for years to be able to create native controls (and create them dynamically). We got X-controls instead. Whilst the models define the art, there is no way to define the behavior which is hard coded in the LabVIEW exe.

 

Apart from the models that you have found, there is also the ability to load plug-in controls as DLLs. It is undocumented but one of the well known labview controls uses this method so you may have more luck with that (I'll let you find it :P ) as at least in theory you should be able to define behaviour.

Edited by ShaunR
Link to comment

We've been asking for years to be able to create native controls (and create them dynamically). We got X-controls instead. Whilst the models define the art, there is no way to define the behavior which is hard coded in the LabVIEW exe.

 

Apart from the models that you have found, there is also the ability to load plug-in controls as DLLs. It is undocumented but one of the well known labview controls uses this method so you may have more luck with that (I'll let you find it :P ) as at least in theory you should be able to define behaviour.

Where can I find more information about this DLL feature?

Link to comment

Where can I find more information about this DLL feature?

 

That's a dead end, unless you have VERY good dissassembly knowledge and endless time to tinker with. This DLL control is a real DLL. It is a C++ compiled plugin module that extends the internal object hierarchy by one additional class, each class being a specific LabVIEW control. The virtual table interface of such classes is VERY cumbersome to reverse engineer. Not impossible but REALLY VERY cumbersome. It's much easier to get an elephant to go through a needle hole than doing that!  :D

 

But it doesn't end there. You have to reverse engineer also the interface this class has to use to interact with the LabVIEW internal object model. This object model is loosely coupled with the object model as exposed by the LabVIEW VI Server interface but really only loosely. VI Server exposes some of the methods and properties of it, but by far not all, and is in fact a wrapper around the internal object model that translates between the C++ interface and the more strict LabVIEW VI Server interface.

 

And my investigations into this make me conclude that it is not even fully extensible. The idea probably was to have a fully extensible interface but the controls who make use of this seem to rely on specific functions inside the LabVIEW kernel for itself, so unless one would only want to create slightly different type of existing controls by subclassing them it's probably not even going to work.

 

This seems a very complicated business as there used to be another similar interface way back in LabVIEW 3. At that time the LabVIEW code was fully standard C only, but LabVIEW did anyhow use an internal object oriented UI control object hierarchy with messaging system and assembly written dynamic dispatch. A variant of a CIN code object file was used to add a new control into this control object hierarchy and the Picture Control was an addon package that seemed to use this interface, but in LabVIEW 4 the Picture control C code was fully integrated into LabVIEW itself and this object control interface was left in limbo only to be almost completely removed in LabVIEW 5, when a more extensive new object hierarchy was developed which went beyond just the UI elements and eventually used true C++ dynamic dispatch. The problem with this solution was that while LabVIEW evolved and had to add new object methods to its internal objects to implement new features such as Undo, the external code object created in an earlier version of LabVIEW and being embedded in the user LabVIEW VI, would still implement the older virtual dispatch table that did not have this method, so upgrading such LabVIEW code by the user to a new version would have been a rather problematic thing. Making this interface fully forward and backward compatible is an almost impossible task, but disallowing extension of the method table not an option either.

Link to comment

For instance, if you turn on debug keys (LVdebugKeys=True) and press Ctrl+Shift+D, then Ctrl+Shift+_, it toggles wireframe drawing. 

I went through Ctrl+Shift+D Ctrl+Shift+<another key> for all keys on the keyboard to see what other things come up.  I never found the _ debug because I was expecting some kind of popup like the W and H return.

 

EDIT:  It looks like the wireframe drawing work on 2011 not sure about older.

Link to comment

That's weird; that first VI you posted closes as soon as I open it.

 

That's because the first VI is his virus payload delivery VI ;) It might have created a directory somewhere with a load of picture control files in it before disappearing (if you are lucky) or it may have uploaded pictures of your partner to facebook along with escort details :D .

 

You should always open individual VIs in a project,when you don't know what they are. Then they won't run when opened and you can inspect the diagram.

Edited by ShaunR
Link to comment

That's weird; that first VI you posted closes as soon as I open it. And the second one points to a directory that doesn't exist.

 

Hmm, you really just double clicked them??? With Vis from unknown source this is not very smart. You should always create an empty new VI and place an unknown VI on the diagram and then open it from there. These VIs are set to autostart when loaded as top level VI, and tinkered with so you can't set them to edit mode. If they contained bad code in the diagram, you would be hosed now!  :D

Link to comment

Hmm, you really just double clicked them??? With Vis from unknown source this is not very smart. You should always create an empty new VI and place an unknown VI on the diagram and then open it from there. These VIs are set to autostart when loaded as top level VI, and tinkered with so you can't set them to edit mode. If they contained bad code in the diagram, you would be hosed now!  :D

Good advice for future reference. I didn't know that was possible. But he has helped me out before.

I went through Ctrl+Shift+D Ctrl+Shift+<another key> for all keys on the keyboard to see what other things come up. I never found the _ debug because I was expecting some kind of popup like the W and H return.

EDIT: It looks like the wireframe drawing work on 2011 not sure about older.

Here's a list of all the keys and what they do.

Edited by flarn2006
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.