Explicit Normals

[Shawn Olson]

I would be awesome if FP could retain the explicit normals of the source geometry. Please consider adding support for this.

[Rokas]

When using Forest Tools to create instances from scattered objects- explicit normals are retained.
Hope this is suitable workaround for You.

[Shawn Olson]

Rokas,

Yeah, I know about this workaround. But it's really not a good solution. It breaks the parametric workflow flow of using Forest as well as introduces performance issues if there are thousands and thousands of nodes. I would love to see Forest simply be able to retain the explicit normal of the incoming meshes. My coworkers and I use Forest for game environments and this is a challenge for us when scattering foliage that has specific normal needs for good lighting when sent to the game engine.

[MattYoungWI]

+1. This would help out a lot!

[ben_img]

+1. Useful thing indeed!

[ben_img]

One year later, is there any news on this retaining normal option ?

[iToo]

No, i'm sorry. We have been very busy lately with other issues (specially RailClone).

I will raise the priority in our wishlist, so it can be implemented as soon as possible.
Just to confirm: do you use V-Ray, isn't ?

[Shawn Olson]

For my purposes, it should not be renderer dependent because I'm sending the mesh data into a game engine.

[iToo]

For my purposes, it should not be renderer dependent because I'm sending the mesh data into a game engine.

Then, are you exporting the full mesh of the Forest objects (as displayed in the viewport) to the game engine ?
It's important for us to understand your workflow, because depending of the process (viewport, render, etc.), the geometry is handled in different ways.

Thanks,

[Shawn Olson]

We have two cases where we are sending Forest data to the game engine:

1) Just transform and object ids... in this case, the explicit normals are not needed because the data for each prop is simply used to place the assets at export time.

2) Clustering: in this case, we are converting sections of forest objects into static meshes--and in this process the explicit normals are needed. This is the case where the current limitations becomes a bottleneck especially if iteration is needed.

[ben_img]

Just wanted to keep this alive.
As the explicit normals would save up a lot of time for game engines indeed...

At the moment i have to use a script to put all the normals up on each forestpro object before exporting, it's quite time consuming!

Cheers

[iToo]

I tried to implement this for FP7, but it was more problematic than expected.

3DS Max uses explicit normals only for viewport models, and requires a specific mesh class to store them. Unfortunately Forest 7 uses a different class to store the geometry, so we should rewrite several parts of the core to support it.
It's doable, and the issue continues in our to-do list. But it requires a lot of code rewrite and testing (to be sure we don't break anything in the process). I hope it can be done for next versions.

[ben_img]

Hi, it's me again

Just back checking about that explicit normals.
Sorry to be a pain.
I've just checked so many alternatives these last months and there are none...

[iToo]

No changes on this yet, i'm sorry.

[ben_img]

Hi, it's me again (again)
wondering if there's been some developpement on that with fp8