I checked the extra output images, subfolders, set the save folders, and hit "Render All To Disk" and nothing happened. No images are saved. I have save the TIF manually from the render window, and get no render elements.
I was thinking Ulco could just render the reflection areas and get the layer elements of it, and then he can project said images as masks to fake reflection while still be true to where it needs to be.
That could work too. But not sure if it would be much faster.
Have you tried to render in a folder you created outside those Windows folders.
I don't use those standard windows folders.
Yeah, that's what it's set to. I made a "MuddyGround" folder under my Terragen folder in Pictures. It's usually defaulted to "My Documents" root, which is strange to me. Not even a Terragen folder created to keep things clean.
I even made and saved to the folder through the "Save" button next to the inputs for the path.
Quote from: Kadri on March 28, 2021, 01:47:36 PMThat could work too. But not sure if it would be much faster.
I think it would be leagues faster cause my idea would be using a custom image for the reflection. The reflection in this scenario is so simple you could get away with a blue reflection, darker at the right side, and a whiter overlay on the left (for where the sun is in mine). That can easily be done with gradients and masked with the reflection masks. No computation of any reflections, in the final render.
PS tried another render and nothing. Not even any errors. Im going to restart my PC. Maybe something in the framework died.
Quote from: WAS on March 28, 2021, 01:52:22 PMQuote from: Kadri on March 28, 2021, 01:47:36 PMThat could work too. But not sure if it would be much faster.
I think it would be leagues faster cause my idea would be using a custom image for the reflection. The reflection in this scenario is so simple you could get away with a blue reflection, darker at the right side, and a whiter overlay on the left (for where the sun is in mine). That can easily be done with gradients and masked with the reflection masks. No computation of any reflections, in the final render.
PS tried another render and nothing. Not even any errors. Im going to restart my PC. Maybe something in the framework died.
If you fake it yes that would be much faster.
Thanks for all your efforts, I really appreciate it. In the end a solution should be pretty fast and easy, because exporting a piece of ground first, cleaning it, fitting it into the TG terrain again so it blends nicely, is quite some work. And it wouldn't have the small overhangs.
The projection of a generic reflection onto a render element mask is probably easier to do, and a great idea.
No idea why it doesn't work like you described. You have to click the button on the right of the name indeed, and really save it to the folder chosen.
But, as said in the other thread; with a much higher roughness (0.2-0.4) for the mud, rendering in PT is much faster than if using less than 0.1. And mud reflections can be a bit softer, so it's no big deal. I'll come back on this in the other thread.
I think something bugged strangely. Restarting and hitting render to disk resulted in all the subfolders and files checked as expected. I had been doing 2 8k renders over night with cores limited to 6 (from 12) so probably overdoing things.
Quote from: Dune on March 29, 2021, 03:05:51 AMThanks for all your efforts, I really appreciate it. In the end a solution should be pretty fast and easy, because exporting a piece of ground first, cleaning it, fitting it into the TG terrain again so it blends nicely, is quite some work. And it wouldn't have the small overhangs.
The projection of a generic reflection onto a render element mask is probably easier to do, and a great idea.
...
Yes and no.
Render elements are obviously very flexible. You can do many things and changes of the look of the render.
But if you change your camera rotation-position you have to do it all over
"is quite some work" Making and using an obj file is actually very easy.
A 800x600 or so render (with atmo and shadows disabled) is very fast.
And you don't even have to clean the file if you don't have an intention to make an animation get too close etc.
I did just used the Terragen exported file as it is in my latest tests here.
The worst part is actually only loading a big obj file when you open the scene.
If you use the ground texturing in the last nodes using only those for the obj is nearly 4-5 clicks.
You can freely change your camera rotation-position (to an extend of course).
Especially if you planned before (just render a wider FOV then you use in the camera or from a little back etc.).
If you want to change the ground look you have to export the ground ones again.
But in this case you have to make the same with render elements too (here you could get away with a crop render maybe).
So depends on what you feel is better for you and-or your workflow.
I haven't exported any ground mesh ever, so I have no idea. But it sounds easy indeed. I'll have a go at it, just the foreground. But then in TG it has to be located to blend in with the more distant area, so the ground has to be lowered where the object comes in.
Quote from: Dune on March 29, 2021, 05:58:00 AMI haven't exported any ground mesh ever, so I have no idea. But it sounds easy indeed. I'll have a go at it, just the foreground. But then in TG it has to be located to blend in with the more distant area, so the ground has to be lowered where the object comes in.
Ulco the ground directly comes as where it is. You don't have to make any adjustements.
If you want only the foreground part you can make that work too.
But first try an all ground work with the default settings.
You might be surprised.
Try with a small export first 600x kinda...
So the exported object has location data within? Interesting.
Yes. You get what the camera sees the same way back.
But Ulco use whatever you feel is better for yourself of course.
As you know there are many ways and different workflows with good and bad sides.
For me the worst with using big objects is loading times and preview problems...kinda.
When you want to go in another place in the scene it might work or not etc.
And having maybe to make another object. You loose kind of that flexibility.
But redoing is actually not hard as i said.
The best is much faster render times nearly all the time.
Just test and see what works best for you.
Yes, I'm curious anyway to see how exporting an obj works. Have to look up how it should be done, which is what I'm doing now.
I would say exporting an object is harder. It could take longer to export and usually needs doctoring. With projection you just render a SR without saving any OBJ and use the saved images in the same project. Yes you can't look around but similar as you told me from doing objects from perspective and not ortho, you dont have much wiggle room with the OBJ either. I dunno if you started doing an ortho so the detail is object-wide.
For me outputting the obj takes much longer than a reflective SR render with layer elements.
Quote from: WAS on March 29, 2021, 12:55:40 PMI would say exporting an object is harder. It could take longer to export and usually needs doctoring. With projection you just render a SR without saving any OBJ and use the saved images in the same project. Yes you can't look around but similar as you told me from doing objects from perspective and not ortho, you dont have much wiggle room with the OBJ either. I dunno if you started doing an ortho so the detail is object-wide.
For me outputting the obj takes much longer than a reflective SR render with layer elements.
I am not saying that it is better. But different workflows for everyone.
I for one would prefer objects. But if you don't it is ok.
As i said above if you render the scene from a little back (from where your camera will be) or use a wider FOV you will get more room to move-rotate. No need for ortho. But you can make a more detailed ortho (you will need a bigger file or make them tiled like Chris) and move even more freely. At least relative to the first method. If you don't move much around and don't have strange problems even an undoctored obj file will mostly work directly exported and imported to Terragen.
If i render two different versions of these methods (standart landscape versus obj) you would have a hard time to know which is which.
But problems will happen if you move a certain way away from the point you made the object.
With this method i can change the camera much more easily and make another render.
With your method it gets (for me) too complicated every time i move-rotate around.
But that is only me and the more ways there are to choose from the better.
I would prefer too see even a basic form how you use your method. By reading i can understand it only so so.
I can't get the appearance to look the same is my issue, and for the time spent just trying to get an object that correctly represents the scene. It takes longer for me to export a proper object. A SR render takes about an hour, it took 3 hours for the last object to finish, which was approaching PT reflection times, which means it was approaching redundancy. Least for my CPU.
And on top of that, if I don't doctor it in Poseray (assuming i can) the obj looks very bad put back in TG.
Jordan if you want, just for an exercise, give me one scene and i will try to make it into an obj only scene
and the same as the standard so good i can.
But it should be a scene i can use my old version.
Changing from the new to the old is too hard. The changes are too much in the versions now.
The differences in CPUs don't seem to help us here. You seem to be able to export OBJs from TG much faster than I can.
Maybe send me a scene to try to export the OBJ from to see how it is on my system. Cause I'm finding exports really slow.
Also trying a new test using a spherical export.
Yeah CPU speed difference is an issue. I wouldn't have done some of the work i did lately.
The animation i am making now for example begun as 10-15 minutes per frame in the first 200-300 frames.
Now every frame takes 1 and a half hour.
With my old pc this would have taken more then 7 hours per frame.
The Ryzen 2600 seems to do pretty good for Gaming, but I am noticing a severe cut in performance from just processors one tier up, or even just the Ryzen 2600X. I want to put a new processor in this PC, but also just wondering if i should get a new bundled PC because the way part prices are.
Ex, I saw a laptop yesterday for 1399 which was about double the speed of this current machine. But only 16gb RAM. But the GPU, CPU, and motherboard were all better.
Go for at least 64 gb ram if you can. After a while you begin just to use more in your scenes.
So a spherical camera also works to do a reflection surface, with a spherical camera for projection. Not sure how accurate that is, but again for such basic reflections in shadow and on mud it's likely all that's needed is those soft sky reflections and some specular.
I think the issue though is the resolution. Now you need a bigger spherical render because it's being overlayed over a larger area. Going to try that to see if it fixes the fuzzy-ness.
Jordan i just made a test. A render of 800x650 exported a 6 gb obj file.
It took nearly 6 minutes for this. I will try to make this exporting to a smaller file and post here if you want to test it (for speed testing).
It uses just a random scene without anything surfaced etc.
You shout be able to post just the TGD and I can export the same OBJ and also see if its near as quick.
This scene took 2 minutes 25 seconds to export a 1.6 Gb obj file.
Have a look Jordan.
It only took 1:52 for me. But again it's a perspective. How is this not different from perspective reflection export? It's only a slice of object in the perspectives view, so you can't look left, or right?
Strangely, also, your atmosphere doesn't render in 3D preview, or in the actual render. o.O Just black sky.
I was curious about adding shaders and such, so I added a PF to simulate some microdisplacement. This reveals polygons. So you would have to may have to use a second compute terrain at the end, and hope you have no lateral stuff, and then export that with all the microdisplacement. Which may take longer. Though you can probably compute normals in another program smaller. Poseray seems to have a set normal resolution based on the geometry or something, so for me I have to set compute terrain patch size very small or textures are blurry up close.
PT render took 8 minutes, so it is much faster, at the cost of quality. Seems all these methods have a quality cost, except probably compositing in Photoshop or another app with layer elements.
Quote from: WAS on March 29, 2021, 05:51:09 PMIt only took 1:52 for me. But again it's a perspective. How is this not different from perspective reflection export? It's only a slice of object in the perspectives view, so you can't look left, or right?
Strangely, also, your atmosphere doesn't render in 3D preview, or in the actual render. o.O Just black sky.
I was curious about adding shaders and such, so I added a PF to simulate some microdisplacement. This reveals polygons. So you would have to may have to use a second compute terrain at the end, and hope you have no lateral stuff, and then export that with all the microdisplacement. Which may take longer. Though you can probably compute normals in another program smaller. Poseray seems to have a set normal resolution based on the geometry or something, so for me I have to set compute terrain patch size very small or textures are blurry up close.
PT render took 8 minutes, so it is much faster, at the cost of quality. Seems all these methods have a quality cost, except probably compositing in Photoshop or another app with layer elements.
Hmm...You see this the wrong way as it looks Jordan.
From your questions it looks like you are always exporting your landscapes wrong, if your exports were long before, as your test of this scene was very fast.
You can disable anything related to shaders except displacements while exporting.
Shadows atmosphere, colours etc. all of them are absolutely not needed. I disabled the atmo and shadows for example.
Those are real 3d polygon objects. No slices (if you mean that).
If you mean that it does have only the part were the camera is looking i already stated that that you have to plan accordingly.
For example for this scene you can put the camera a little further forward. Then you can go a little to the left, right or back and can rotate for example...Or just make a spherical (haven't tried one spherical rendered obj) render export or just 3-4 ones for all sides.
And by adding more detail to this object that is what you shouldn't do actually. You can do it of course if you want.
But the real purpose is adding every detail first in your normal landscape and exporting that as an obj file. Not later.
If you add everything you want and export that, the exported obj file will have all those detail already having in it.
So the render time won't be longer later at all.
We are talking about this but for a normal fast non problematic rendering scene without reflection etc. i doubt if you would need this.
Planning or not, in the end the most flexible way is using Terragen without this kind of landscape export and import.
If you want to use the landscape in another software that is another thing of course.
I use this mostly for animation. When you render 2000 frames, half hour versus 1 hour (for example) makes a huge difference (84 days versus 42 days).
But for just an image that takes even 3-5 hours i wouldn't bother.
You can make for example something like this with your cave scene.
It took from the beginning to the end just 1 hour 10 minutes to make;
exporting the obj, animating, rendering and even making it twice as long in Project Dogwaffle.
If you like movies like Yasujirô Ozu this kind of camera moves are even like a Bourne movie :)
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.
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.
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.
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.
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.
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.
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.
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.
What do you mean by patch size, of the compute terrain? I don't use any.
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.
XYZ shader would be enough, or transform set to world for detailed shading. Only if you need slopes, better to use computes. IMO.