OctaneRender™ Standalone 3.05.1

[abstrax]

Hi all,

To fix a regression in the geometry compilation that inverted the vertex normals of subdivision surfaces, we are releasing an update with some additional small improvements.


Changes since version 3.05:

• Added pins to specify a ground colour and the transition from sky to ground colour to the daylight environment node.
• The daemon list shows the computer name of the master that is bound to a daemon, which allows you to figure out who is currently occupying it. We will add a button to "steal" a slave from another master in one of the next releases.
• When you save the current render view via one of the viewport save buttons, the filename will be initialized with the current render target name.
• Added the possibility to give linker nodes a description, which is displayed as a tooltip - similar to the description of pins. To change the description (or its group) you right-click on the linker node in the node inspector and select "Edit linker info".
• Changed the upper limit of "turbidity" in the daylight environment node to 15, which strongly attenuates the sun.
• Replaced the pin "distributed ray tracing" in the info channels kernel node with a new enum pin "sampling mode" - which does the same as the pin in the render passes node.
• Fixed the incorrect naming of the info passes sampling mode pin ID. As a consequence, the sampling mode pin will not be loaded correctly from files that have been saved with 3.05. Older and newer files should be loaded correctly.
• Fixed inverted vertex normals when the geometry is subdivided.
• Fixed UI freeze when FPS is set to 0.
• Fixed box mapping when used in a emission distribution texture.
• Optimized the film buffer sizes for the wireframe passes and deep pixel rendering.
• Lua: Added documentation of the various script graph input fields, you can use in octane.scriptgraph.setInputLinkers().
• Lua: Added new field description to the pin infos you specify in octane.scriptgraph.setInputLinkers(), which allows you to give input linkers a useful description.

OctaneRender Standalone downloads

Windows
commercial version (installer)
commercial version (ZIP archive)
subscription version (installer)
subscription version (ZIP archive)
demo version (installer)
demo version (ZIP archive)

Mac OS X
commercial version (DMG image)
subscription version (DMG image)
demo version (DMG image)

Linux
commercial version (ZIP archive)
subscription version (ZIP archive)
demo version (ZIP archive)


Photoshop workflow plugin download

You can download and install the plugin either via the Adobe Exchange platform or you can download it from the link below and manually install it.

Windows and Mac OS X
- Photoshop extension (v1.0.3) (ZXP archive)


Happy rendering,
Your OTOY NZ Team

[glimpse]

Now that's a great addition! ("The daemon list shows the computer name of the master that is bound to a daemon, which allows you to figure out who is currently occupying it. We will add a button to "steal" a slave from another master in one of the next releases.")

Question: what if in a small studio environment we would have 2-3 Master rigs (1-2 GPUs PCs) & powerful NODE (let's say 7-8 GPUs). Is it possible to use NODEs GPUs by different team members at the same time (2x for one user, 5X for another)?

Thanks

[manalokos]

Just found a bug in the interpolation of pixels in a texture, that is caused by some UVW mappings.

interpolation-problem.jpg

I have attached a obj file that you can apply a texture and see the problem, there are 2 grids in the file one is correct the other shows the problem.
This also happens in 3.04.4, 3.05

Kind regards
Filipe

[mojave]

Just found a bug in the interpolation of pixels in a texture, that is caused by some UVW mappings.

interpolation-problem.jpg

I have attached a obj file that you can apply a texture and see the problem, there are 2 grids in the file one is correct the other shows the problem.
This also happens in 3.04.4, 3.05

Kind regards
Filipe

The UV coordinates of the mesh causing the mapping issue are in the order of tenths of thousands, is there a reason for that?

The artifacts you see are caused due to precision issues: for performance purposes all texture fetching functionality is performed using single precision floating point arithmetic, which on the other hand may cause precision loss the further from zero your coordinates are, which is not usually the case.

[manalokos]

Do you mean this cannot be fixed?
How can I work around this? This causes problems in bumpmaps, ie. anisotropic shaders, and can be visible in some cases.

[mojave]

Do you mean this cannot be fixed?

It would probably require some significant changes as there's no native harware support for fetching textures using double precision at the hardware level, but ewe could look into it if there's a significant number of users that require this feature.

How can I work around this? This causes problems in bumpmaps, ie. anisotropic shaders, and can be visible in some cases.

The best way is to make sure your UV information has the right scale, which is usually in the range [0, 1].

[manalokos]

Ok, I will try that! Thanks for the information.

Kind regards
Filipe

[mojave]

Question: what if in a small studio environment we would have 2-3 Master rigs (1-2 GPUs PCs) & powerful NODE (let's say 7-8 GPUs). Is it possible to use NODEs GPUs by different team members at the same time (2x for one user, 5X for another)?

To achieve this you may use the --gpus command line option of the Octane daemon, which lets you specify the IDs of the GPUs used by it. You can see the IDs in the File > Preferences... > Devices section in Standalone by selcting a device and checking the value in the field "PCI bus id".

Then you may run more than one daemon using different ports and GPU partitions, to which your masters in each team will connect.

[PolderAnimation]

We found a problem with bumpMaps in this release ( and probably others )

Our setup ( included in the zip file ) :

octaneBumpArtifacts.zip

1) We export an alembic with 2 spheres, both have 2 uvSets. The first sphere has 2 different uvSets, the second 2 identical.
2) We import the alembic in octane, assigns a shader and plug a random noise map in to the bump pin.
3) everything seems to work fine
4) we set the bump image to use uvSet 2
5) Now the first sphere, which has 2 different uvMaps shows weird artifacts. ( See attached image )

2balls.png

The problem I think exists because to transform the bump values in to a normal map ( I presume this is the way to offset the normals ) the shader always samples the first uvSet for the normal and a mismatch exists between the normal of the first and second uvSet.

Is there a work around for this, except for not using more than 1 uvSet?

Cheers

[roeland]

Those artefacts are there because the bump map has different scales on different parts of the sphere. If a bump map is scaled down, the “bumps” become smaller but they still have the same height. As a consequence they become steeper so they will appear stronger in the rendered image.

Not sure what the final desired effect is, but you can use a Noise texture to create the bump map, with a Multiply to change the “strength” of the bump effect. This is a 3D texture so you won't get any seams on a sphere.

--
Roeland