I created a simple triangle in a blender with three vertices.
The picture shows the coordinates in the blender.
I export the model with default settings, including "+Y up"
However, here are the vertexes that the .bin file contains.
vertexes:
-1 0 2
1 0 1.5
0 0 -3
indeces
0 1 2
As can be seen, the Z-axis values have changed sign.
Why so?
My guess:
Blender as far as I understand uses left-side coordinate system, and gltf uses right-side coordinate system, maybe that's why it changes the Z-axis.
But, the gltf specification says: "glTF defines +Y as up, +Z as forward, and -X as right;" why then does the X axis not change? After all, in blender +X is right.
Related
For example I created a sphere in blender, and exported the obj file. I was noticing some issues in my shader, because all the vertex normals for a face are the same. And can see it directly in the .obj file itself, such as portion below, see that for the first face, all the verticies are using normal index 1. I would expect they should all be different since it is a sphere, and are curving. Thanks, also this is in Blender 3.1
f 10/10/1 9/9/1 22/22/1 23/23/1
f 6/6/2 5/5/2 15/15/2 16/16/2
f 480/526/3 10/10/3 23/23/3 24/24/3
f 7/7/4 6/6/4 16/16/4 17/17/4
f 481/527/5 480/526/5 24/24/5 25/25/5
I found the issue, and I needed to add shading to the object in blender. Edit Mode->Select all vertices, and select smooth shading.
I'm using the following extension method I built on top of itext7's com.itextpdf.layout.Document type to apply images to PDF documents in my application:
fun Document.writeImage(imageStream: InputStream, page: Int, x: Float, y: Float, width: Float, height: Float) {
val imageData = ImageDataFactory.create(imageStream.readBytes())
val image = Image(imageData)
val pageHeight = pdfDocument.getPage(page).pageSize.height
image.scaleAbsolute(width, height)
val lowerLeftX = x
val lowerLeftY = pageHeight - y - image.imageScaledHeight
image.setFixedPosition(page, lowerLeftX, lowerLeftY)
add(image)
}
Overall, this works -- but with one exception! I've encountered a subset of documents where the images are placed as if the document origin is rotated 90 degrees. Even though the content of the document is presented properly oriented underneath.
Here is a redacted copy of one of the PDFs I'm experiencing this issue with. I'm wondering if anyone would be able to tell me why itext7 is having difficulties writing to this document, and what I can do to fix it -- or alternatively, if it's a potential bug in the higher level functionality of com.itextpdf.layout in itext7?
Some Additional Notes
I'm aware that drawing on a PDF works via a series of instructions concatenated to the PDF. The code above works on other PDFs we've had issues with in the past, so com.itextpdf.layout.Document does appear to be normalizing the coordinate space prior to drawing. Thus, the issue I describe above seems to be going undetected by itext?
The rotation metadata in the PDF that itext7 reports from a "good" PDF without this issue seems to be the same as the rotation metadata in PDFs like the one I've linked above. This means I can't perform some kind of brute-force fix through detection.
I would love any solution to not require me to flatten the PDF through any form of broad operation.
I can talk only about the document you`ve shared.
It contains 4 pages.
/Rotate property of the first page is 0, for other pages is 270 (defines 90 rotation counterclockwise).
IText indeed tries to normalize the coordinate space for each page.
That`s why when you add an image to pages 2-4 of the document it is rotated on 270 (90 counterclockwise) degrees.
... Even though the content of the document is presented properly oriented underneath.
Content of pages 2-4 looks like
q
0 -612 792 0 0 612 cm
/Im0 Do
Q
This is an image with applied transformation.
0 -612 792 0 0 612 cm represents the composite transformation matrix.
From ISO 32000
A transformation matrix in PDF shall be specified by six numbers,
usually in the form of an array containing six elements. In its most
general form, this array is denoted [a b c d e f]; it can represent
any linear transformation from one coordinate system to another.
We can extract a rotation from that matrix.
How to decompose the matrix you can find there.
https://math.stackexchange.com/questions/237369/given-this-transformation-matrix-how-do-i-decompose-it-into-translation-rotati
The rotation is defined by the next matrix
0 -1
1 0
This is a rotation on -90 (270) degrees.
Important note: in this case positive angle means counterclockwise rotation.
ISO 32000
Rotations shall be produced by [rc rs -rs rc 0 0], where rc = cos(q)
and rs = sin(q) which has the effect of rotating the coordinate system
axes by an angle q counter clockwise.
So the image has been rotated on the same angle in the counter direction comparing to the page.
The width of a line in PDF is defined in terms of distances in the user space. In my use case, the aspect ratio of the device space (e.g. 4:3) is different from the aspect ratio of the user space (e.g. 1:1), which causes the line widths in the device space to be different in vertical and horizontal directions.
For example, in this picture the horizontal and vertical lines should be of the same width, but they're not:
I would like to perform scaling that only results in line width uniformity and does not affect anything else.
I asked a similar question regarding PostScript here: How to ensure line widths are the same vertically and horizontally in PostScript?. A solution based in part on the answer to this question works for PostScript, but does not work in PDF after what seems to be an almost one-to-one translation.
I tried changing the stroke command S to q 1 0 0 1.5 0 0 cm S Q h, where q saves the graphics state, 1 0 0 1.5 0 0 cm scales the current transformation matrix, Q restores the graphics state, and h closes the current subpath. However, in addition to correctly scaling the line widths, this also scales the y-coordinates of the line endpoints by 1.5.
This is what I need to get:
But with q 1 0 0 1.5 0 0 cm S Q h, I get this instead:
How to make the line width uniform in the device space in PDF without affecting anything else?
I am trying to get a mesh of the cerebellum. The issue is that the mri volume does not have a high enough resolution to enable a reliable identification of different substructures so what i am doing is parsing svg files of delineations of histological staining slides and converting them into filled masks kind of what you would get after using polygon tool on one slice of the mri volume. I do this for around 20 slices.
Can i load a labelled volume in snap where each voxel is labelled with an id corresponding to some structure and each structure has its own rgb color code kind of like the load label feature. When i load this volume into snap will snap recognize the labelled voxels and allow me use interpolate label features for interpolating these labels to unlabelled slices and then do a export mesh. Right now what im doing is
import nibabel as nib
import numpy as np
d3 = fixed_3d.astype("int16")
d3[210,:,:][ind] = 1 # ind is the coords inside my structure
new_image = nib.Nifti1Image(d3, affine=np.eye(4))
nib.save(new_image, "vol.nii.gz")
fixed_3d is my atlas volume then i load this in itk snap and also do a import label . my label file looks like
IDX -R- -G- -B- -A-- VIS MSH LABEL
0 0 0 0 0.00 0 0 "Clear"
1 48 126 110 1.00 1 1 "arb"
But when i click on export as surface mesh i get the message missing mesh for selected label
I think you are missing a step of registering histology slides to MR image. Otherwise your workflow looks good.
I've been having a bit of a problem with making the Y axis my up axis when exporting mesh and scenes from Blender. Both Blender and my export target use right handed transformation matrices. Z is the up axis in Blender while Y is the up axis in my target. The problem exists in 2 places though. The scene's transformations can't just be shifted on the X axis to fix this, because I also need to do the Y/Z switch for the vertices in the mesh (export as vertex.x, vertex.z, vertex.y). I need to have the actual Y and Z rotations switched, so that if the Y and Z rotations are the same, no change will occur (ie. identity). Thanks for your help in advance. Feel free to ask questions if I was not thorough enough.
Blender does two things different than the rest of the known world!
1. It uses Z axis for vertical (should be Y); Y axis for horizontal (should b X); and X axis for in and out (should b Z).
Very weird! Every high school graph since the beginning of time uses X for horizontal and Y for vertical.
It uses the right mouse button for selections.
U can change the selection btn in Preferences, but not the crazy axis arrangement!
no,
you do this
y=z
z=-y
no rotation of 90 degrees can make you go from left to right hand.
I ran into a similar issue when working with cinema4d and blender. In cinema4d Y is the up axis and rotations are heading,pitch and bank.
Blender's system looks like a right handed system, but rotated by 90 degrees on x axis.
I did the same thing for coordinates(exported as vertex.x,vertex.z,vertex.y). For rotations,
I think you should add 90 degrees(math.pi * 0.5) for rotations on X axis and the rest should be fine.
HTH
Have you tried just using Select All (the 'a' key) and then r x 90 to rotate everything 90 degrees around the X axis and the pivot point? (your pivot point is choosable in the menu bar of the 3D view if you need to control that).
You could do that, export, and then undo.
Just Download Wings3D. Export from Blender as .3ds and then Import this file in Wings3D.
Now you can just export it from Wings3D, again to .3ds. But instead of clicking directly on .3ds, click on the small icon in the right of the ".3ds" menu. now you can unchecked the Box Swap y und z axis and import the .3ds in another program.
There is no way that would be possible. Coordinate system was innately selected as hard coded from the blender source and there are no explicit option has been made in blender to switch it. It would also affected many of the hard coded functionality of any function blender was used or has been made by assume that coordinate
However, in theory, it would be possible to access blender source code and rebuild the blender to have it use another coordinate we would like. Albeit we need to carefully swap everything related to coordinate system
I too wish that left handed coordinate system (as of Unity3D) would be industrial standard and blender should at least have another version that work in left handed coordinate. People should just graduated from table coordinate to screen coordinate already
In blender, you could add empty plain axes, that will correct your orientation when exporting to unity, or try exporting as fbx file and change orientation in export options