I want to write a parser for Blender's .obj file. The file format seems self explanatory, but also it seems to be missing some data. For example, a simple cube (the default Blender cube) has 8 lines of vertexes, but I was expecting to see 36 lines (12 triangles to form a cube).
I think the confusion, at lease for me, stems from the way cubes are created in direct3d. Direct3d requires 36 vertexes to form a cube. So I am thinking that I need to infer the other 28 vertexes. This type of guessing could cause issues later on when trying to parse vertexes for more complex shapes. So, I thought if I could find the official specs on the file format it might provide me with some insight into how to interpret the data.
It seems that someone else had asked the same question before: How to get proper number of vertices in OBJ file from DCC tools such as Blender for use in OpenGL ES?
but it didn't have any useful information for me.
OBJ Spec
MTL Spec (you'll probably want this too at some point)
FYI OBJ is in no way related to Blender, it's just a common file format for simple models.
Related
I am trying to read the view angles from a Sentinel-2 image (L1C SAFE compact format) for executing an atmospheric correction algorithm. I can get those values by parsing the file MTD_TL.xml, but I am not able to get them through rasterio.
I have tried to access to those data using the xml:SENTINEL2 and the xml:VRT metadata domains, but I can only access to the values from the file MTD_MSIL1C.xml (the main metadata file).
The whole point of using rasterio is being able of using GDAL's virtual file system, as the images will be read from S3 buckets. Any alternatives for easily reading MTD_TL.xml through the virtual file system would be also valid (and really appreciated).
Thank you!!
I answer to myself.
I could not find how to get the values I require, but according to https://gdal.org/user/virtual_file_systems.html the function VSIFOpenL may be used for opening the file. After that, manual parsing will do the trick :)
Ps. I must read the documentation slowly.
I have been exploring Maya's blendshapes for the past weeks, and it has one very interesting feature called in-between targets. It basically allows one blendshape to include intermediate states between the two basic targets (modified and original objects). I created a couple and tried to export in FBX to use them in Blender, and I get an error message. This error does not occur when I import a FBX file without in-between targets in the blendshapes. Also, I wasn't able to find a pure Blender solution to create Shapekeys with in-between targets, which got me wondering if it is even possible.
Any help is appreciated.
Blender only provides support for one vector per vertex per shapekey so the in-between targets will not be able to be imported directly. I would suggest you report this as a bug, while I don't expect in-between shapekeys to be added any time soon, the fbx importer should be fixed to not break on these files.
One thing you could to try is to see if you can export the shapekeys to an mdd or pc2 file. Blender has a mesh cache modifier that can be used for these files. From 2.78 a new option to try is exporting to an alembic archive as outlined here
While blender doesn't support in-between shapekeys, you can create a comparable result using drivers. A single control can be made that can enable a series of shapekeys one after the other.
I am using trying to setup an arbitrary GOP structure (a GOP structure other than hierarchical B or IPPP...) in HM-16.3. I fiddled around with the configuration file setting up the GOP pattern. However, I do not know how I can force the encoder to choose a particular reference frame from a list of reference frames in the reference picture set. Is this even possible in the reference encoder?
It is possible to change the GOP structure of the HM without manipulating the source code and only with the config parameters.
You are right, it's way too complicated.
I can explain it here but surely I can not explain it as good as the way it is explained in the reference manual.
And it seems that you've just done it with trial and error.
Take a look at this manual at page 3.
Also this is an example of how it works:
When solving problems with many (changing) constraints or objective components it is pretty hard to create documentation in form of formatted equations for it.
Is there an easy way to automatically create formatted equations (LaTeX, PDF,..) from LP/MPS files?
This would be a big help for me.
Thanks in advance!
See https://cs.stackexchange.com/questions/48510/help-wrapping-my-head-around-a-combinatorial-optimization-problem/50179#50179 for an example of a LaTeX representation of a GAMS model. I think with LP/MPS files you have lost too much structure and context. It would be very difficult to recover the original equations that formed these files. Almost like recovering the original C code from a .exe file.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I'm looking for a way to remove all path objects from PDF file.
I suspect that this can probably be done with javascript in Adobe Acrobat, but would really appreciate a tip to do it with ghostscript or mupdf tools.
Anyhow any working solution is acceptable as correct answer
To do this with Ghostscript you would have to modify the pdfwrite device. In fact you would probably have to do something similar for any PDF interpreter.
What do you consider a 'path' object ? A shfill for example ? How about text ? How about text using a type 3 font (which constructs paths) ?
What about clip paths ?
If you really want to pursue this I can tell you where to modify pdfwrite, provided you don't mind recompiling Ghostscript.
Its probably a dumb question, but why do you want to do this ? Is it possible there might be another solution to your problem ? If all you want to do is remove filled paths (or indeed stroked paths. One solution would be to run the file through ps2write to get PostScript, prepend code to redefine 'fill' and 'stroke' as no-ops, and then run the file back through pdfwrite to get a PDF.
[Added after reading comments]
PDF doesn't have a 'path' object, unlike XObject which is a type of object. Paths are created by a series of operations such as 'newpath', 'moveto', 'curveto' and 'lineto'. Once you have built a path you then operate on it with 'fill' or 'stroke. Note that PDF also doesn't have a 'text' object type either.
This is why your approach doesn't work, you can't remove 'path objects' because there aren't any, the paths are created in the content stream. You can use a Form XObject to do something similar, but then the paths construction is in the Form content stream, it still isn't a separate object.
The same is true of PostScript, these are NOT any kind of object oriented languages. You cannot ' detect vector object of type path' in either language because there are no objects. In practice anything which isn't an image is a vector object, and is constructed from a path (and with clipping, even some images might be considered as paths)
The piece of PostScript you have highlighted adds a rectangle to a path (paths need not be contiguous in either PDF or PostScript) and then fills it. Note that, as is usual practice in PostScript, these are not directly using the PostScript operators, but are executing procedures which use the operators. The procedures are defined in the program prologue.
By the way, it looks like you used the pswrite device here (can't be sure with such a small sample). If this is the case you really want to start with ps2write instead. Otherwise you are going to end up with an awful lot of things degenerating to tiny filled rectangles (pswrite does this with many image types)
I didn't suggest that you try to 'decrypt' the ps2write output (it isn't encrypted, its compressed).
What I suggested was to create a PostScript file, redefine the 'show' and/or 'fill' operators so that they do nothing, and then run the resulting PostScript program back through Ghostscript using the pdfwrite device. This will produce a PDF file where all stroked and/or filled objects are ignored.
[final addition]
I picked up your sample file and examined it.
I presume the bug you are seeing is that the PDF file uses a /Separation colour (surely it cannot fail to fill a rectangle) with an ICCBased alternate and no device space tint transfrom. In that case the current version of ps2write may solve your problem. It (currently, this is due to change) does not preserve /Separation colours and instead emits them as a device colour, by default RGB. So simply converting the files to PostScript and back to PDF may completely resolve your problem.
If you knew what the problem was, it would have been quicker if you had told us, I could have given you that information and work-around in the first place.
Using ps2write I then created a PostScript version of the file (notice that the Separation colours are now RGB) and prefixed the PostScript program with two lines:
/fill {newpath} bind def
/stroke {newpath} bind def
Note that you must use an editor which preserves binary. Then running that PostScript program back through Ghostscript using the pdfwrite device I obtain a PDF file where the green 'decoration' which I think you are having a problem with is gone.
So, there's a solution to your question, and a possibly better way to solve your problem as well.