No Extra Output Images

Started by WAS, March 28, 2021, 01:30:42 PM

Previous topic - Next topic

WAS

You aren't understanding. I added shaders to the object to demonstrate how easily destroyed it is. This is a probable for a final scene and all the extra shaders added and reapplying them without a different look because you're adding the same shaders on baked geometry. It has its purposes for sure, like you say animation where things are in motion and not studied so closely.

Kadri


No i understand. The point is you shouldn't add anything related to displacement later to get such a problem.
You should add only the colour parts of your shaders.
As the displacement is already in the object (if you did it right the first time).
As i said you can add detail later if you want. But that can bring some problems like you said with it.
The best is to think about the shaders with this workflow in mind. And it isn't so hard as it looks.

WAS

Thus, not really workable for most TG scenes utilizing the Shaders group to apply all sorts of microdisplacement that the Compute Terrain would smooth or render wrong. Honestly at this point I wouldn't advise it's use for Ulco circumstance for a close up shot like he's doing.

Kadri

#33

Close up or not is not the problem Jordan...It will export what it sees.
A problem could only begin when you go closer then when you made the export.

Mostly i don't make the final Texturing before exporting. I make the displacement first and export.
I make the final texturing after i import the object.
With a standard landscape use this wouldn't be important.

And Ulco using or not using is up to him.
As i said i wouldn't even bother for just an image myself.

WAS

With such a high patch size that texturing is slow, though, no? And yes thats what I was demonstrating by adding shaders. Which microdisplacment is part of that... Unless you do a tiny patch size and small scales, but OBJ will be slower and certain geometry may not export right. I cant make this method look good for close up. Maybe hidden with objects and very little showing.

Kadri

#35
Quote from: WAS on March 30, 2021, 12:14:38 AMWith such a high patch size that texturing is slow, though, no? And yes thats what I was demonstrating by adding shaders. Which microdisplacment is part of that... Unless you do a tiny patch size and small scales, but OBJ will be slower and certain geometry may not export right. I cant make this method look good for close up. Maybe hidden with objects and very little showing.

You are still thinking in the "Terragen landscaping way". Forget it.
Just think that you imported an OBJ Tree object and will texturing it.
With such an imported object you know what limits there are.

You have, by making an object (landscape) first in Terragen much more possibilities then importing any other object.
Nobody knows how much detail you wanted or you got into the object. If the final look is good that matters.
So half a millimetre less displacement or more isn't important.
For example in this 2 renders is the difference really so big as you say?
https://planetside.co.uk/forums/index.php/topic,29012.msg286058.html#msg286058
And this is with an undoctored only 600 mb obj file.

And if you don't get the detail you want. Just render the standard way. It is always there.
You don't have to use this method. I use it only when i have to for fast rendering.

The detail part is much better then you think actually...but anyway...I am beginning to write the same things over and over.

Dune

You guys covered a lot of ground while I was snoring. Interesting. As I wrote in the other thread, it may indeed not be what I need for this particular render (speed problem solved), but it's interesting for me to see how it works for future stuff.

WAS

#37
What I am saying is I don't think the final scene with obj will represent the original scene with actual shader work. Reflections are not using texture coordinates from what I can see (looks the same with any patch size) so not the best gauge. When you apply PFs, or even images, with a 20 patch size the octaves of the PFs will be very low compares to the source PF, because of the UV normals from the patch size. And lowering the patch size dramatically increases render time.

Take a look at the OBJ rocks I was exporting, ill see if I can find a link. With patch size 20 there was almost no texture detail, bump, etc from the PFs for the default shader. I had to render with patch size 0.1 for 1m rocks. And said rocks end up being GB plus for a 1m obj. So that with a landscape... Yeah. Lol

I have done this a lot, for UE and stuff and the results are all garbage unless from a distance when fully textured.

I look forward to seeing your result.

PS trees are not a good example cause like I am trying to explain for a long time their normal/UV scale is much smaller, around the areas I am talking about, 0.1-1 in terms of patch size, which influences obj export. All these tests with just reflections don't mean much for normal/UV scale of the object for a scene standing in the mudpit with the characters in a foreground setting.

Dune

What do you mean by patch size, of the compute terrain? I don't use any.

WAS

I wonder what influence that has on shaders. I haven't tried myself. I know if you use it, its like stretching your textures by a factor of "20" or whatever (with default of 20). They all apply super blurry, whether image or PF, and have to have a small patch size. I can't imagine without it its very small considering how fast it renders.

Dune

XYZ shader would be enough, or transform set to world for detailed shading. Only if you need slopes, better to use computes. IMO.