Most of the time I import a dxf file it makes a huge mess. We need DXF files for 2d paths but when the file is imported the lines are broken up and more points are inserted in and lines join several points all over. I have been doing some research for that last few hours I did find the R12 Autocad DXF Reference. I did find out that I can look at a DXF file in notepad.
But I was hoping someone might shed some light on the question
How does DXF define a path in regards to points?
It could be that I would read the whole R12 DXF reference and not know a thing more than I did before about how to understand DXF better.
I'm not ignorant to the software world MAX Blender Acad. But feel out of sorts with DXF
I do a lot of eps or AI from an image and then import that in Cad and Export to DXF for CNC plasma cutters and CNC water cutter... My goal is to understand what is going on much better so I can create these files for these CNC machines. The Vicon plasma cutting machine does not USE G-Code like a lot of other machines. But the others use G-code and M-Code Its all so fascinating. But they all seem to except dxf as an import. Often they will hang on an import because the DXF file splits up points into millions of little segments and hangs the system. Often they are older XP machines.
What I am after is any information that may get me pointed in the right direction. Should I study the DXF reference first?
If you have read the DXF reference, I expect you are aware of SECTIONS, the interesting section for you is the ENTITIES section, which contains the entities of the modelspace.
Important entities for 2d paths are:
LINE
ARC
CIRCLE
POLYLINE
The first 3 (LINE, ARC, CIRCLE) are self contained entities, the entity starts with the structural entity tag (0, LINE) and ends with the next structural entity tag (0, ENTITYNAME).
The POLYLINE entity is a combination of 3 entities:
0
POLYLINE
...
0
VERTEX
...
0
VERTEX
...
...
0
SEQEND
The POLYLINE entity contains all the information about the line properties, the VERTEX entities defines the vertices (points) and the SEQEND entity marks the end of the POLYLINE entity. The VERTEX entity can contain bulge values, which defines ARC segments in the POLYLINE.
If there are INSERT entities, than its getting more complex, the INSERT entity describes the insertion location, rotation and scaling for a BLOCK reference, I assume you will ignore entities located in 3d space by using OCS and extrusion. The BLOCK itself is defined in the BLOCKS section and has the name referenced by the INSERT entity. The transformation of the entities in the BLOCK definition into the modelspace (or another BLOCK definition, BLOCK contains INSERT) has to be done by yourself.
That should be a starting point to read DXF R12 file, for writing R12 files, there is a little bit more to know, but not much more, in fact it is enough to write only the ENTITIES section to create a valid R12 file (don't forget the (0, EOF) tag), but without the ability to use different line types or text styles, different layers can be used, layers work without a definition in the LAYER table.
Related
Context: I've been extracting geometry data from the Forge SVF structures into an OBJ format using the Forge Extract code by Petr. These data are then transparently sent to a different rendering system for the project upon which I'm working. However, I'm noticing that there are incorrect rotations in groups of extracted objects. Not all objects, just groupings.
As an example, here is the Forge Viewer rendering of a group of objects (the long poles), with correct rotation. You can see all the poles evenly placed along the base-plate's edge and equally placed with regards to each other.
Whereas in the rendered extracted geometry, the grouping of objects are correctly placed with relation to each other (equally, 3x3), but the group as a whole is rotated slightly along the Z-axis in relation to the bottom plate.
This is the type of behaviour I would expect if the individual poles were all child objects of some parent object (perhaps an invisible grouping object), and the rotation of the parent would pivot all the poles in the SVF but that rotation wasn't applied during geometry extraction.
This happens with all groupings with regards to individual objects in a scene.
While looking at this question, I get the strong impression that there is a 2nd rotational aspect but I cannot see how that applies when reading the SVF directly.
Question:
Obviously I'm not looking for a direct code solution, but to confirm the structure of the SVF pack files. Looking at the extraction, I don't see anything which would imply a parent-child grouping but haven't managed to think of an alternative cause.
So, are there such parent-child transform relationships in the SVF pack files, or a global rotational component which only applies to certain objects? If so, where is that placed within the pack file. And if not, what else could cause this type of systematic rotation of groups?
The SVF file format doesn't use parent-child transforms - all fragment transforms are basically world transforms. It's possible that my code for parsing the fragment transforms handles one of the transform types incorrectly. I'd try debugging the getTransform method for the dbId of the base or one of the poles, and compare the transform with the one parsed by Forge Viewer.
Also, I'm wondering if it's the base that's slightly off, and not the 3x3 poles?
I'm dealing with DXF files in Python. Reading only.
So far every file I've opened has Polyfaces defined (besides of Lines, arcs and circles...). I'm planning to do all my calculations using polyfaces only. But I'm afraid that some other 3D software saves a DXF without a polyface in it. Since I couldn't find any information that tells me they are mandatory I want to know how to be safe that my code will not fail by lack of polyfaces.
Should I trust more in Lines and Arcs instead? Are they mandatory?
In the 'Animation / Skinning / Blending' Three.js example, the JSON model (the Marine) has multiple animation tracks (idle, walk and run). These are stored in an "animations" array in the JSON file.
My question is two-fold... Firstly, how do you "label" the animations in 3DS MAX? I tried using an FBX Multi Take plugin which does allow me to add some marking. They are present when I re-import the FBX file back into Max but do not show up when I try to export to JSON... which is my next question....
How do you then export these animation states? When I use the 'ThreeJSAnimationExporter' from within 3DS MAX, there is no option to define any animation tracks (nor will it pick up the ones I defined in the question above), it just exports everything into 1 animation. This is stored in an "animation" (not "animations") array in the resulting JSON file?
The JSON file of the Marine must have been created somehow... can it be done in MAX? If it is only possible in Blender then is there any way I can get my models and animations from 3DS MAX to Blender as I am trained in MAX and don't particularly want to learn Blender, even though it does look very good these days.
Thanks in advance.
P.s. I am using the MAX exporter that ships with r71 of THREE.js.
I have managed to get this working but it requires a lot of inelegant hacking of JSON files and excessive file duplication in MAX. Basically I have created multiple MAX files with the same rig, skin, weights, UV's and materials. I then animated each track of animation and export it using the existing ThreeJSAnimationExporter. I then open up the JSON files, extract the animation entries and combine them into a single JSON file with an "animations" property array instead of a single "animation" property. You can then rename the animation segments from 'Action' to something more useful.
If anyone has a more elegant solution I would love to hear it.
I would also love it if the clever person who created the original ThreeJSAnimationExporter script could create a new script called ThreeJSBlendedAnimationExporter which allows for a simple animation track input system, it would only need a start frame, end frame and animation label for each animation track (segment). And for the love of god, also address the smoothing while you're at it :)
General question: What is a stable JSON format for loading 3d models that is currently widely used?
Extended question:
I'm a programmer doing some WebGL stuff, particularly with the Elm programming language.
I've been looking at different model formats, and it seems like using the three.js JSON format as a kind of standard makes a lot of sense for my project (and potentially for the langauge in general).
However, on the three.js github, it says that version 3 of the model langauge is soon to be depricated.
So, I'd like to know the current status of the model format before I convert. Is version 3 stable for the time being? Has version 4 been released? Will there be a version 4 model format, or is it being replaced by the geometry format? Are the upcoming changes so breaking that adopting the format at this point in time is a bad idea?
I've seenthe new ObjectLoader classes, how do these relate to the Json mesh formats? Is it a format that I can convert .obj to?
To follow up on my github post:
To be honest I don't think its safe to say that version 3 was never too stable. 3 has always had issues and the SceneLoader class that supports grew to be kind of unfriendly to maintain. Now 4 is pretty stable just lacking in support for textures. It is fine for objects, geometry, and materials but there is no exporter yet (that I am aware of).
Now what I think you are most curious about is the actual model format, which is this:
https://github.com/mrdoob/three.js/wiki/JSON-Geometry-format-4#example-of-geometry
To be honest the actual geometry format hasn't really changed much that I can tell. The big change between 3 and 4 (so far) is the scene formatting. In fact geometry is parsed with the JSONLoader class. In fact a couple days I committed, to dev branch, a new example file for msgpack compressed JSON scenes.
https://github.com/mrdoob/three.js/blob/dev/examples/webgl_loader_msgpack.html
msgpack is just JSON compression, so when it is decoded it is a JSON object. This msgpack file was converted from three.js/blob/dev/examples/scenes/robo_pigeon.js
This scene is a version 4 scene format. Each entry in the "geometries" table is actually an embedded geometry format. This format can also live in an external file. If you compare it to the first link you will see the formats are the same. Geometry files can be individually loaded into a scene with JSONLoader.
Now you asked about converters: glancing at convert_obj_three.py it says "JSON model version," in the documentation so I am going to guess it spits out a basic geometry model format and not a scene format so this may be usable. Even the blender exporter can still export compatible geometry scenes (leave the "Scene" option checked off). How do I know? Because the geometry I used for robo_pigeon.js came from that exporter, I just had to construct the version 4 scene by hand.
Does this begin to answer your question?
According to mrdoob he is planning to change the geometry format but as of this very moment the version 3 model format works fine in a version 4 scene because ObjectLoader passes those geometry (model) definitions to JSONLoader. So until a new format is actually spec'd out and JSONLoader is updated the version 3 model is the current one.
One more note: scene loaders (SceneLoader, ObjectLoader) don't natively load geometry. They always dispatch the tasks to the correct class. Not sure if it is supported yet in version 4 but in version 3 you could directly link the scene to OBJ files. And speaking of OBJ files, if you are just starting to poke at three.js and have assets in OBJ then have you considered just working with the OJBLoader directly?
This is a two part question.
1) Is there any way to get a csv file of all the entity data, including xdata, for an autocad dwg, either using autocad or some other method?
2) Is there an easy way to parse a autocad dxf file to get the entity data into a csv file?
Unfortunately, neither approach provides an easy method, but it is possible with a little effort.
With a DWG file, the file itself is binary so your best bet would be to write a plugin or script to AutoCAD, using .NET or ObjectArx, but this may be a troublesome approach. AutoLISP would be easier, but I don't think you could output to a file.
Getting the enitity data out of a DXF would be significantly easier, since the DXF is primarily a text format. This would be possible with any programming language, but since there are many possible entities it would take some effort to handle all of the cases. The DXF reference is available at the AutoDESK website. XData is certainly also included in the DXF in a text format, so that shouldn't be a problem.
You can write output to a file using autolisp, even binary output with some slight of hand. However, writing dxf data to a csv file, with or without xdata, by either reading the data directly (in-situ) or by parsing a dxf file, is completely impractical, given the nature of dxf group codes and associated data. Perhaps the OP can identify what he wants to achieve, rather than specifying what appears to me to be an inappropriate format for the data.
Michael.