Obj Smooth Surface Normals

[Ashley]

Hi,

I have a high poly obj loaded (approx 10mil polycount) and want to smooth its surface normals.
Is this possible? and how?

Note: I have "Use smooth normals" checked on the obj loader, but it doesn't do anything?
Is there a tolerance setting I need to twerk? or (for TG) should I be exporting objs without normals?

FYI I noticed the "height" constraint of the distribution shader doesn't work with objs?
However the "slope" constraint works fine. 

Cheers
Ash 

[Dune]

Perhaps if you take it through Poseray; weld vertices there and set smooth normals, then recalculate.
For height you'll need to use Y or final.

[Matt]

"Use smooth normals" causes it to load the normals that are saved in the OBJ file, if there are any. There isn't a threshold to tweak because it expects everything to have been worked out in the program that saved the file. We are planning to add an auto calculate normals feature in future, however.

Matt.

[Ashley]

Thnx Dune. I had forgotten to switch it to final

As for the obj, I had a look at the .obj file in a text editor and found the reason.
Zbrush exports the vertex normals as a .mtl file. Terragen can't read this and throws up an error.

Most other 3D apps export the vn in the .obj file, or they simply create vertex normals when an .obj is loaded without vn.

EDIT: Ah I thought so. Good to hear Matt, thnx for clarifying that :-)

[bobbystahr]

Thnx Dune. I had forgotten to switch it to final

As for the obj, I had a look at the .obj file in a text editor and found the reason.
Zbrush exports the vertex normals as a .mtl file. Terragen can't read this and throws up an error.

Most other 3D apps export the vn in the .obj file, or they simply create vertex normals when an .obj is loaded without vn.

EDIT: Ah I thought so. Good to hear Matt, thnx for clarifying that :-)

As Dune said PoseRay fixes all .mtl ills and any texture you see in PoseRay you will see in TG......I run all .obj objects thru it as a matter of course.
I often do retexturing in PoseRay as it's a bit lo res but fast.

[Ashley]

Thnx bobbystahr, the thing is I don't want to use Poseray ;-)
I think the issue is pretty straight forward, most other 3D apps do export a TG friendly obj.

Although I'm glad a fix is on the way, imo using obj in TG for a terrain instead of using heightfields isn't efficient.
Vector disp will be the way forward, once that is ironed out.

[bobbystahr]

Thnx bobbystahr, the thing is I don't want to use Poseray ;-)
I think the issue is pretty straight forward, most other 3D apps do export a TG friendly obj.

Although I'm glad a fix is on the way, imo using obj in TG for a terrain instead of using heightfields isn't efficient.
Vector disp will be the way forward, once that is ironed out.

Out of curiousity, why do you not want to use PoseRay? Saved my bacon innumerable times.

[j meyer]

Vector disp will be the way forward, once that is ironed out.

What's the problem with Vdisp at the moment,if I may ask?

[Ashley]

@ bobbystahr
Personal preference, I try not to over-complicate workflow. I'm not convinced adding 1 piece of software for a singular task, save obj with vector normal, will give me the return for the initial outlay of resources.

Other apps I currently use can already give me this.
Hypothetically speaking lets say TG absolutely required poseray to import obj terrain models correctly...I simply wouldn't use TG for obj editing. In fact my experience moving terrain data between other apps works nicely with heightfields.
So I don't actually need to import obj into TG other than to check my heightfields are the right size. For all other terrain elements such as rocks/ trees etc, I use other apps.

Adopting new software and integrating it represents many aspects which require R+D. From personal experience TG has made some leaps and bounds recently, why stop short now? Keep the momentum going and develop tools that make TG a core app.

[Ashley]

@j meyer
Vdisp just hasn't been easy or consistent for me. I feel like this is also not confined to TG, but other apps as well.
I have gotten results before but those "settings" didn't work across different terrains.

I've read on other posts here there is some development happening in the area of Vector disp, and that is what I was referring to. Waiting to see what Matt has cooked up before I jump back into Vdisp, commit time to R+D and update my workflow.

For example, I spent many hours of personal time developing a cloud library. When I wanted to test it in my comp I found self shadows had not been dealt with in a clean way. This lead me to further explore other solutions. So for me clouds in TG awesome, great for painting with not able to integrate with a dynamic camera move due to lack of proper shadows AOV.

Having learnt my lesson I'm not going to devote time to VD until it is fully fledged in TG and other apps.
Don't get me wrong I really dig where TG is going, any info I share is in the hope it gets there faster.

[bobbystahr]

@ bobbystahr
Personal preference, I try not to over-complicate workflow. I'm not convinced adding 1 piece of software for a singular task, save obj with vector normal, will give me the return for the initial outlay of resources.

I understand, and my affection for the app comes from before we had the much improved .obj handling we have now...I did say as a matter of course, heh heh...back then to import a model with more than I think 19 parts shaders you had to break it up. But this is way off from what you're doing and you have it seems an adequate pipeline so...heh heh heh, as you were.

[Matt]

Zbrush exports the vertex normals as a .mtl file. Terragen can't read this and throws up an error.

Can you send me one of these files?

Matt

[j meyer]

Thanks for your answer Ashley.

Curious about the vertex normals in the mtl also,especially as I couldn't find
any VNs in any of my old files.Neither .obj (which I knew) nor .mtl.
Still have to test with the latest version,though.

[Ashley]

@jmeyer I realized after posting you might be referring to using the vector disp with function nodes.
I've seen this work perfectly, although I've not used it. I was only talking about using Vdisp maps from other apps. I've not had much joy, if you got a bullet proof method I'm all ears. 

As for the obj, when I compare both files I notice the vn set of values absent from the zbrush exported .obj

v = vertex,
vn = vertex normal
vt = I think this is UV co-ord
f = ?

So the components of a .obj from Modo (This might be standard across major apps).
v -22.5804 32.2109 99.999
vn 0.554508 0.743886 0.373035
vt 0.81451 0.08871
f 4209/342/352 4205/337/347 1091/341/351 4207/344/354

The zbrush .obj is similar to this, missing the vn values. I think it uses .mtl for that as a separate file.
v -22.5804 32.2109 99.999
vt 0.81451 0.08871
f 4209/342/352 4205/337/347 1091/341/351 4207/344/354

I might be wrong but it looks like TG doesn't like this?

Cheers
Ash

[j meyer]

I was asking,because I don't know,if you saw oysteroid's post here
http://www.planetside.co.uk/forums/index.php/topic,16110.msg192785.html#msg192785

And for the missing vertex normals:some years ago I noticed that ZBrush doesn't export
normals with .obj files.Same reason as yours the missing smooth normals effect.
Iirc Oshyan made me look at the .obj file in a text editor back then.
After seeing this thread I had a look at some of my old ZB generated .mtl files and
none of them contains any vn values at all.
Do you have a .mtl that actually shows vn values or do you assume they are in the
.mtl files?

As far as I know ZB exports smooth normals with .fbx files nowadays,but I can't test
that myself.