Why no # comment for instances in OBJ Exports?

iancgbelliancgbell Posts: 16

I know there are scripts available to "bake" instances into more objects and bloat the OBJ file even more; but how hard would it be for Daz to add an OBJ comment  specifying an instance to its OBJ export?

 Something like

# Instance: Plant_v001 34,220,0, 1,0,0 0,1,0, 0,0,1

where Plant_001 is the name of a preceeding  'o' tagged OBJ object, and the following 12 floats are a translation and an orientation.

 Obviously no existing OBJ parsers will be looking for this and will just ignore it like any other comment; but the OBJ parser I'm working on would, as could others. 

 It would be comparatively easy for Daz to add such comments, and the benefits would be dramatic. Daz would';t even need to extend the OBJ Export Options UI to allow enabling such comments, since they are only comments and so can't break anything.

 

 

Post edited by iancgbell on

Comments

  • It's a nice idea, and as a writer of obj importers and exporters I like the way you suggest it's done. But... adding proprietary extensions to existing widely used formats rarely ends well - saved from catastrophe by wrapping it as a comment. You need wide acceptance, trying to get DAZ to add in a comment applicable to only your modeller is as likely to be accepted as if I ask them to do something just for my modeller. Zero, I fear.
  • iancgbelliancgbell Posts: 16
    edited January 11

    Parsable # comments wouldn't be only applicable to my modeller (Solidworks) once other modellers realised it was there and exploited it. Once some modeller's start allowing fast import of "unbaked" OBJ instances, there is pressure on other modellers to start "fully supporting comment-extended OBJ".

    I'm not sure what you mean by "proprietary extensions" here. I'm not claiming any sort of ownership of such "comment commands"

    I said it would be easy for Daz to add such comments, but the hardest part would be extending Daz .OBJ input to honour them.  That would be more significant coding, but not that hard.

    If you like the idea, why not add # Instance comments to renderosity OBJ exports/imports? Then Rendorisity will have a slight advantge over Daz with regard to Solidworks.

    The other # comment I suggest is one I have been adding by hand to Daz OBJ using UltraEdit. It is # Collection: name

    What "# Collection: Plants"  does on .OBJ input parsing is look through an existing array of names for "Plants". If it finds it, it sets the current collection index to it's position, otherwise it adds "Plants" as a new name and sets collection index to the last in the array. From now untill the next # Collection: comment, all OBJ 'o' objects are considered to be in the "Plants" collection.  I use this to impose a simple 2-level hierachy on the otherwise flat 'o' object list in the OBJ file corresponding two the top two levels of the Daz hierachy.

    Adding # Collection: comments to Daz OBJ exports would be even easier than # Instance: comments. But I'm asking mainly for # Instance: because # Collection is far easier to add by hand.

    Incidentally, parsing OBJ # comments for model data is not unprecedented. I think some OBJ exporters include units information (meters,inches,...) in an early comment.

    # Collection hierachy for SW Daz OBJ import

     

     

    Post edited by iancgbell on
  • I ran into a wall seeing your modeller is SolidWorks.

    It's the one I use too (2014 at home, 2020 at work), but have never been able to sensibly export to obj even when using the ScantoCAD plugin. I end up saving to .stl, convert to .obj usng my own convertor (stress tested with 11.5 million facets/550Mb STL file). And then in my modeller I have just (last 2 weeks) written a de-triangulate method to minimise the number of sharp triangles. The other use for my modeller is to apply material zones & groups, and basic texture mapping (Current View or Box) before export to DS. If it's possible to go straight from SolidWorks to obj without needing the .stl intermediate file, I'd love to know how...

    I also have written an importer in my modeller to read the .geo output from SW Simulation, but the difficulty is then identifying and deleting all the internal facets from the pyramidal elements created by simulation.

    Importing into SolidWorks, well yes, that works via ScantoCAD but the model is rarely usable in SolidWorks after import, particularly if the import is a character, and I seem to end up with a rigid mesh surface that's impossible to do anything with.

    Regards,

    Richard

     

  • iancgbelliancgbell Posts: 16
    edited January 11

    Solidwork doesn't export OBJ even now; only STL, PLY (untextured), and 3MF (textured). It imports OBJ (untextured native, or badly-textured via ScanTo3D addon) or 3MF (textured, multimaterials in 2022). Your best bet in 2020 is probably 3MF. If you can find a 3rd Party 3MF<->OBJ converter that works well for you, you might be able to roundtrip through SolidWorks and keep the (monotransparent)  textures

    I'm currently improving the native OBJ import to support textures and variable transparency, hence my interest in Daz OBJ export, but this won't be till 2023. I doubt there will ever be a SolidWorks OBJ Export.

    I'm pushing for .FBX import/export support and haven't been told 'No' yet, but if that happens it won't be till at least 2024.

    Cheers, Ian

     

    Post edited by iancgbell on
  • Hmm. Just looked at the .ply and .stl models output from a part I'm working on. The facets are identical, as are the vertex positions. The sole difference being that the vertices need merging in the .stl file, hinting at a preference to use the .ply format to me. The .3MF format, not being a plain text format, is a little harder to work with as far as I can see.

    My main use is to model in SW, use in DS. However, having a two way easy exchange may open up further possibilities.

    Regards,

    Richard.

     

  • iancgbelliancgbell Posts: 16
    edited January 11

    One way to gain greater control of the SW export tessellation is to use ConvertMeshBody to create a mesh surfaces body (I think that's in 2020) from the analytics, then export that mesh body as STL or PLY. SW can also import/export .CGR if that helps.

    Post edited by iancgbell on
  • My. Been using SW since 2006 and never seen 'Insert| Features| Convert to Mesh Body' before [shakes head in astonishment]. That, combined with my new de-triangulator, will improve the output mesh enormously. Thank you.

    Regards,

    Richard

  • WendyLuvsCatzWendyLuvsCatz Posts: 31,884

    it does define coordinates, I have imported obj files into other softwares and there is a label or null for each instance at the point the instance is and of you export an obj at 0,0,0 you can send it or copy paste it etc to that point,

  • iancgbelliancgbell Posts: 16

    I don't follow what you mean by "there is a label or null for each instance at the point of the instance". We are talking about DAZ exported .OBJ  files here. Is there already something in them I've missed?

  • iancgbelliancgbell Posts: 16

    richardandtracy said:

    My. Been using SW since 2006 and never seen 'Insert| Features| Convert to Mesh Body' before [shakes head in astonishment]. That, combined with my new de-triangulator, will improve the output mesh enormously. Thank you.

    Regards,

    Richard

    SolidWorks Convert To Mesh Body is comparatively recent. 2018 or 2019 I think.

  • WendyLuvsCatzWendyLuvsCatz Posts: 31,884
    edited January 11

    I only am going by what imports, I haven't examined the obj file itself and if I did, wouldn't know what to look for,

    there are several export options that can make a difference.

    You need groups checked and I think offhand existing checked, will need to look as not done one without using the instances to objects script for a long time. 

    it also depends on what program you are importing into.

    In my case 3DX6 for iClone6 has the names of the instances which is what I refer to as labels or nulls in the hierarchy you can attach then chose position and rotation.

    I don't of course know what you are importing into.

    Unreal Engine and Twinmotion which is built with Unreal engine the instances labels while visible are useless as the pivot for everything is globally set to 0,0,0

    the program you are importing into has to see things in local space or have an option to set the pivot to local space like Carrara I also use does.

     

    Post edited by WendyLuvsCatz on
  • Cheers. I'll look at my home (2014) copy this evening to see if it's there, probably isn't.

    Regards,

    Richard

  • iancgbelliancgbell Posts: 16

    I do have Write Groups enabled. I can't find an "existing" option in Daz OBJ Export options.

    One way to embedd instances in OBJ without using # comments would be to have a suggestively named 'o' object with no facets or polylines and just four "isolated" vertex defining a located vector triad.

     The parser could then use these to create "null" object hooks onto which other actual 'o'  obects with facets could be copied.

  • WendyLuvsCatzWendyLuvsCatz Posts: 31,884
    edited January 12

    Highlighted in image, I will need to find something with instances to test which choice

    and OMG this forum

    there are multiple posts in this thread that were not here when I posted

    not the first time this has occurred, I look extremely stupid and irrelevant in my replies simply because I only saw the first couple of posts, probably a Cloudflare caching thing.

    sorry

    I see now you are trying to import i to Solidworkss, on that I have no idea

    Capture.JPG
    451 x 504 - 46K
    Post edited by WendyLuvsCatz on
  • Wendy, it's the export of obj files that should be discussed. I unfortunately derailed the discussion, but maybe it should get back on track.

    Regards,

    Richard

  • WendyLuvsCatzWendyLuvsCatz Posts: 31,884

    it's fine, I am no help to the OP either as his software may not read the information the same as some of mine, it certainly varies a huge amount, things explode in some Twinmotion being the worst if parented not in place for example the very same obj file that works perfectly in iClone.

  • iancgbelliancgbell Posts: 16

    I tried OBJ Export with Use Existing Gropus enabled and didn't get any form of instances in the .OBJ output I could see.

    I think what needs to happen here is for Daz to come in and either say "Oh, thats a good idea!" and add unbaked instance hints to the .OBJ export; either via # comments outside the OBJ spec, or via helpfully named no-facet four-vertex hook  'o' objects within the OBJ spec.

    Or say: "We are already doing something similar, you need the following Export settings...."

    Then I can make the Solidworks OBJ Import recognize them, and other packages that are minded to can extend their OBJ import; and people won't need to bloat OBJ exports to unreasonable sizes with baking scripts any longer.

     

     

  • iancgbelliancgbell Posts: 16
    edited January 13

    I know there are scripts available to "bake" instances into more objects and bloat the OBJ file even more; but how hard would it be for Daz to add an OBJ comment  specifying an instance to its OBJ export?

     Something like

    # Instance: Plant_v001 34,220,0, 1,0,0 0,1,0, 0,0,1

    where Plant_001 is the name of a preceeding  'o' tagged OBJ object, and the following 12 floats are a translation and an orientation.

     Obviously no existing OBJ parsers will be looking for this and will just ignore it like any other comment; but the OBJ parser I'm working on would, as could others. 

     It would be comparatively easy for Daz to add such comments, and the benefits would be dramatic. Daz would';t even need to extend the OBJ Export Options UI to allow enabling such comments, since they are only comments and so can't break anything.

    Or rather than using # comments outside the .OBJ spec, Daz could export instances as helpfully named no-facet four-vertex hook  'o' objects within the OBJ spec, the four positions defining a located vector triad

    Either way,  I can then make the Solidworks OBJ Import I'm working on recognize them, and other packages that are minded to can extend their OBJ import; and people won't need to bloat OBJ exports to unreasonable sizes with baking scripts any longer.

    Post edited by Richard Haseltine on
  • WendyLuvsCatzWendyLuvsCatz Posts: 31,884
    edited January 13

    you could use

    https://www.daz3d.com/alienator-pro

    to replace instances with proxy objects like a cube

    then use instances to objects (you have already mentioned)by the same Premier artist to create those cubes as actual placeholder objects

    Post edited by WendyLuvsCatz on
  • iancgbelliancgbell Posts: 16
    edited January 14

    There is nothing I can use within Daz because I am not trying to export my own models from Daz into SolidWorks,

    I am trying to allow any Daz user to export a scene like HD Scans Garden Ponds which makes heavy use of instances into SolidWorks via OBJ without those users having to exploit such tools and possibly bloating the OBJ to the point of unusability.

    What I can do to further this end is extend the SolidWorks OBJ Import to look for and implement "instance hints".

    But I can only do this if there are "instance hints" in the OBJ. And such can only be added by extending Daz OBJ Export to include them.

     

    Post edited by iancgbell on
  • WendyLuvsCatzWendyLuvsCatz Posts: 31,884
    edited January 14

    well then you need to look at the SDK I guess

    I know of at least one person who created their own obj exporter for their plugin bridge because the default didn't do what they wanted but it was specific to the target program Virtual World Dynamics 

    I of course don't know how to do anything of that nature, I just work with the tools others make.

    maybe post in the Developer's forum

    https://www.daz3d.com/forums/categories/daz-sdk-developer-discussion

    Post edited by WendyLuvsCatz on
  • Beginning to think that you may need to write a script in DS to a) write the normal obj file and then b) append the information you want to be written as comments to the end of the obj file as the next part of the script iterates through the scene, identifying each instance and writing the transforms for the object as a comment. I think this should be do-able.
  • iancgbelliancgbell Posts: 16
    edited January 15

    It would be doable, but then I'd have to add notes to the Solidworks documentation saying that if SolidWorks Users want to import OBJ from Daz scenes with Instances, they'll need to run my Daz script in Daz, to improve Daz's OBJ Export

     That's not my job. My job is making SolidWorks OBJ Import support whatever instance hints may be present in SolidWorks Users' OBJ files.

     Putting some form of instance hint in Daz OBJ Exports is Daz's job.

    Post edited by iancgbell on
  • WendyLuvsCatzWendyLuvsCatz Posts: 31,884
    edited January 15

    it's actually not their job cheeky if they see no need

    I also cannot help as something has changed in later builds of DAZ studio and I too can no longer export empty instance labels

    I would need to find an old exported obj file if I still have any to see what is different 

     

    Post edited by WendyLuvsCatz on
  • Ian, please look at your messages (acessible through the gear wheel at the right of the blue bar at the top of the forum page).

    Regards,

    Richard

Sign In or Register to comment.