Notiusweb wrote:vijay_thirukonda wrote:
Vertex normals from the file are useless when a subdivision is applied on a mesh, so we will have to calculate it on runtime. I guess the problem is the winding order of the body and hands are not same, you can confirm it by rendering the character in the wireframe info channel kernel with wireframe backface highlighting enabled.
Hi-
Just to give all, both of these scenarios have the issue when checkbox for 'Load Vertex Normals' is off:
SubD off
ABCSubD_Off.2.png
WireFrame_NoSubD.jpg
SubD on
ABCSubD_On.png
WireFrame_SubD.jpg
Is there a way I can make Octane calculate Vertex Normals at runtime, I wasn't sure if it is a setting somewhere?
THX!
I had a look at the scene you sent to me and the problem is that the body mesh is split into separate mesh objects. Currently there is no way to "fuse" them back to one mesh in Octane. Since the subdivision is done on a per-mesh basis, the subdivided meshes will be discontinuous which becomes very obvious when looking at the sub-divided normals.
This means that the only way to solve the problem is to export the geometry as one mesh object.
In case you are interested: When you load an Alembic or FBX file, the created nodes are contained in a geometry archive, which is just a "fancy" node graph. By default Octane doesn't allow inspecting these node graphs, because they can contain tens of thousands of nodes or people might start deleting nodes and changing connections, etc., which would break the geometry. But you can tell Octane to allow you inspecting geometry archives by enabling the log flag
makeAllInspectable. I.e. create a log flags file
octane_log_flags.txt in the same directory where the Octane Standalone binary can be found and write
makeAllInspectable into it. After restarting Octane you will be able to inspect loaded Alembic or FBX geometry archives. This might make it a bit more clear what is happening with this scene.
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
