Xform Nodes not working?

[treddie]

Any ideas yet, Roeland? Not sure all that you guys have on your plate, so if you can;t get to it right now, that's cool.

[roeland]

I can't see anything without the mesh files. But some thoughts about what you can do:

If the meshes are exported in inches I recommend changing the import settings of your meshes to inches, then you don't need the extra scale.

Otherwise if you want to scale everything in the scene it is easier to do this with a single placement node between the geometry group and the render target.

You can also replace these groups of three placement nodes with one node, since version 1.21 the three transforms are applied in this order.

--
Roeland

[treddie]

I'm a numbskull, Roeland...I sent you the scene but not the meshes. Here is a zip containing everything.

Transform Nodes Problem.zip

(3.65 MiB) Downloaded 130 times

I forgot that Octane has had inches for some time now. That will definitely simplify things.

Otherwise if you want to scale everything in the scene it is easier to do this with a single placement node between the geometry group and the render target.

Good point. I was thinking that Scale always had to be done first, so that meant doing it individually to each mesh. But I realize now that's making a mountain out of a molehill...Doing it last simply scales an entire geometry group after any other transforms have been applied.

The reason I liked the old separate nodes for each transform was to help prevent accidental changes to one transform while trying to change another. All it takes is a sloppy turn of the mouse wheel over the wrong field, and without Undo, the old setting is gone forever.

[roeland]

This one seems to work fine. Just your measurement seems a bit off, the distance between the two holes is around 0.984 inch, rather than .9775 inch. If you switch to an orthographic camera and via the toolbar set the camera to the top view, then the distance between the left and right side of the image is exactly equal to the value in the "Scale of view" input of the camera. If you set this to .9775 you can clearly see the distance between the holes is slightly bigger.

--
Roeland

[treddie]

Then the problem is in Octane when it imports the image. I have taken the mesh and imported it into ProEngineer to check its size and the value is definitely .9775. Therefore, Octane must be rounding the mesh down or doing something else to cause it to be off.

[roeland]

Then ProEngineer is a bit off. I checked in Cinema 4D as well, and if you set a measure with a length of .9775 (the object was imported in meters) then you see that one of the end points of the measure is off-center.

--
Roeland

[treddie]

Roeland,

First I need to apologize...I originally sent you only the scene file and forgot to also send you the meshes. Then earlier today, I sent you the wrong, uncorrected mesh for the base. So I feel like I'm sending you on a wild goose chase.

So here is the correct set of meshes, which includes the corrected base I have been using. The problem is still there, but now my original mesh error is not compounding the problem.

Another resaon that I know that the problem has to be in Octane 1.2x is that in 1.2, the problem does not exist. And what is interesting is that if you load the old v1.2 scene into v1.26, the problem does not exist. So that looks like something going on in the v1.26 nodes.

In this new zip, please find two scenes...One for the old Octane v1.2, and the other for v1.26.

Both scenes load the same meshes, and these are the correct meshes now.

Sorry for the headache.

Transform Nodes Problem (CORRECT MESHES).zip

(11.18 MiB) Downloaded 118 times

[roeland]

The old file is using a scaling factor of 0.0250 for the base while the new file uses a scaling of 0.0254. So the correct translation value in the old file is -0.0244375 and in the new file it is -0.0248285 ( = .0254 * -.9775).

Another thing that may help here: the last couple of release candidates have a hidden feature int the numeric input boxes, you can fill in basic expressions and Octane will then calculate the value.

--
Roeland

[treddie]

Ahhh, OK then. I see that now when viewing the .ocs file in a text editor. Thanks for the clarification.

So it boils down to the current Octane practice of always rounding down displayed values. In other words, I probably saw the .025, not realizing that it was really .0254 (which is the correct conversion from inches to meters). But this is a perfect example of my other thread in the Release Candidate Testing forum, titled "Significant Digits". So my 'worst' fear came true. By rounding down values, I simply copied the scale values from an existing node to another. But because they are all rounded down, direct copying is not possible. And going back and proofing my work did not help because the original displayed values were now lost to history...except deep inside the .ocs file.

Can I STRONGLY suggest that the fields NOT round down values? That one had me going for a long time.

[treddie]

Was curious if Otoy has any plans on the following?
1. Displaying more than 3 decimal places in textboxes.
2. When copying/pasting nodes, the information recorded in the .ocs file be used for values, not the rounded down displayed values, like what you see in placement nodes.