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 :)
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.
"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.
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 :-)
Quote from: Ashley on September 19, 2015, 04:28:58 AM
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.
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.
Quote from: Ashley on September 20, 2015, 06:50:28 PM
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.
QuoteVector disp will be the way forward, once that is ironed out.
What's the problem with Vdisp at the moment,if I may ask?
@ 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.
:)
@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.
:)
Quote from: Ashley on September 21, 2015, 02:36:37 PM
@ 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.
Quote from: Ashley on September 19, 2015, 04:28:58 AM
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
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.
@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
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.
Ah yeah, that thread is a good read. I have seen it before, in fact it was the first attempt I had with VD out of Zbr.
Following it I was able to get a result, but only from lots of tweaking.
Do you have a .mtl that actually shows vn values or do you assume they are in the
.mtl files?
I was thinking a similar thing, maybe I could copy past the vn into one file. But no when I open the .mtl its just container for maybe .bmp assignment?
Its another Zbr quirk but it would be good to have TG generate normals, or I wonder if there might be a way to assign these inside an .obj internal network?
Cheers
Ash
I'm pretty sure smoothed surface normals are embedded in the .obj mesh.
When setting up smoothing groups, it's part of the poly edit process not the texturing.
Quote from: Ashley on September 22, 2015, 03:56:33 PM
Its another Zbr quirk but it would be good to have TG generate normals, or I wonder if there might be a way to assign these inside an .obj internal network?
Can you take your zbrush mesh into a 3d app and apply auto smooth, setting your angle threshold between surfaces to define hard edges in the smoothing groups?
Just been looking on Modo forums. Modo seems to use smoothing in texture only, where as Maya and Max bake that data onto the mesh. It maybe worth asking someone with the app to help out. Otherwise download a 30 day trial if you're in a fix. As I said earlier, .obj exports smoothing withing the mesh data and not in the .mtl file.
Thnx Hetzen,
It's all good, just confirming that indeed that was why TG didn't smooth.
Cheers
Ash
It's not a ZB quirk - from my point of view - but a way to keep .obj file sizes
kind of moderate.Ever tried to add normals to a high poly mesh? I did. Sizes
can get really much bigger.
Anyway,cool you got it sorted. :)
Quote from: j meyer on September 23, 2015, 11:52:12 AM
It's not a ZB quirk - from my point of view - but a way to keep .obj file sizes
kind of moderate.Ever tried to add normals to a high poly mesh? I did. Sizes
can get really much bigger.
Anyway,cool you got it sorted. :)
That's a good observation. I've noticed the same mesh from Zbrush, exported from Maya is significantly larger.
Zb can handle about 1.3GB obj file on import. So that's a nice tip to load heavier meshes.
fyi I like the quirky apps ;-)
So does TG export vn with the obj?
If so is there a way to disable this? Zbrush taps out at loading obj larger than 1.3gigs.
As pointed out above, not saving vn with obj lowers the file size.
This might be a good feature for those exporting massive terrains.
Cheers
Ash
The Micro Exporter allows you to choose whether or not to export normals. The same for UVs.
If exporting an OBJ from some other kind of object, it depends whether normals were loaded in the first place, which depends the "use smooth normals" in that object's settings. If you turn that off, really what it's doing is stopping it from importing normals in the first place, so then there are no normals to save, so it won't try.
Matt
Awesome, I totally overlooked that attr 8)
Cheers Matt ;D