Water shader crashing

Started by rolland1013, May 29, 2019, 01:17:23 pm

Previous topic - Next topic

rolland1013

Hi,

I keep running into this problem and am wondering if there is a solution someone could offer.  I've created geometry in Maya and have imported it into TG.  I want to use the water shader on it, but every time I assign the shader, TG crashes.  Is there some limitation to the water shader that I'm not aware of? 

I've attached the files if you want to try it yourself.

I'm using build 4.4.18.frontier

cyphyr

works for me ...
www.richardfraser.co.uk
https://www.facebook.com/RichardFraserVFX/
/|\

Ryzen 9 3900X @3.79Ghz, 64Gb (TG4 benchmark 6:20)
i7 5930K @3.5Ghz, 32Gb (TG4 benchmark 13.44)

Oshyan

Seems to work here as well. Can you detail exactly how you are attaching it and at what point it crashes? Immediately after connecting the Glass Shader (i.e. before render)? If that's the case, try Pausing or Closing the 3D preview, or switch to RTP and see if it still occurs.

- Oshyan

rolland1013

Sorry for my late response.   The way I was attaching the water shader was selecting the shader node and assigning a new water shader (see image).  TG would crash within seconds of doing this.  I tried both of your suggestions Oshyan; I closed the 3D preview window and that seemed to fix the problem.  I also switched to RTP, that also worked.  Thanks for the suggestions!!

Niel

WAS

Likely a thread dumping issue. Happens to me all the time if I forget to close/pause the [basic] 3D preview.
Check out my Terragen Discord: https://discord.gg/Vy5FRTE

raymoh

Similar here.  Terragen crashes often when the adjustments of a shader (water, grass, reflective...) are changed while the 3D preview is still running with the "old" values. It seems that Terragen ( the 3D preview) reacts only delayed (or with a crash) to spontaneous and sudden changes and adjustments while rendering the preview. Why not implementing an automatic stop for the basic 3D preview, during sudden changes and "live" adjustments by the user and then restart it?
Beauty is in the eye of the beholder.

Oshyan

July 12, 2019, 04:03:47 pm #6 Last Edit: July 12, 2019, 04:11:08 pm by Oshyan
OK, with the updated instructions I've been able to potentially replicate this. Which hopefully means we can resolve it! Thanks for those details.

- Oshyan

Dune

What Raymoh says sounds familiar to me, and a temporary stop might be a good idea. I never wait for the (normal) preview to finish and make all sorts of adjustments and usually all goes well, but ocassionally when doing a simple change TG crashes. With RT preview I am more careful, hardly ever have it on when doing changes, except on clouds, as I found it more prone to crashes.
On another note, preview restarts also after changing the size of the crop; is that necessary?

WAS

Quote from: Dune on July 13, 2019, 01:46:34 am
...
On another note, preview restarts also after changing the size of the crop; is that necessary?


I've noticed this too. I think I mentioned it before. It's usually not too much of an issue, but if I'm cropping to something very specific, and than the preview explodes into polygons before I've cropped in the other side of my selection so I'm unsure of where to put it and rely on where I believe it should be or wait for the preview to finish.
Check out my Terragen Discord: https://discord.gg/Vy5FRTE

Dune

If I want to change a crop precisely and not have it build up again from scratch, I sometimes remember to pause preview before changing it. So, no, luckily it's not a big issue, just noticed it.

jaf

July 13, 2019, 06:32:54 pm #10 Last Edit: July 13, 2019, 06:35:51 pm by jaf
Wouldn't there be a way in the software to not allow a change if there is any rendering in progress?  It shouldn't allow a change while any render is in progress. ༼ ◕_◕ ༽ 
(24jul19) Ryzen 1800x, 970 EVO 1TB NVME-M.2 SSD, Corsair Vengeance 64GB DDR4 3200 Mem,  EVGA GeForce GTX 1080 Ti FTW3 Graphics 431.60 (24jul19), Win 10 Pro x64, Terragen Frontier 4.4.18 BMark 0:10:18

Oshyan

3D previews aren't the same as renders and shouldn't block users from making changes. In general change detection works well to restart the preview based on the updated info. In some cases the preview is restarted too quickly or too often and it wastes time and resources, which is something we need to solve. But I don't think it's necessarily reasonable to assume that the crash(es) reported here are to do with the simple fact that the 3d preview is working while you are making changes. That's by design. From my testing that's not actually what seems to trigger this particular bug anyway, although there may be multiple issues occurring here. Anyway, we'll track down as many of these problems as we can.

- Oshyan

WAS

July 13, 2019, 09:30:48 pm #12 Last Edit: July 13, 2019, 09:36:33 pm by WASasquatch
Quote from: Oshyan on July 13, 2019, 07:06:00 pm
3D previews aren't the same as renders and shouldn't block users from making changes. In general change detection works well to restart the preview based on the updated info. In some cases the preview is restarted too quickly or too often and it wastes time and resources, which is something we need to solve. But I don't think it's necessarily reasonable to assume that the crash(es) reported here are to do with the simple fact that the 3d preview is working while you are making changes. That's by design. From my testing that's not actually what seems to trigger this particular bug anyway, although there may be multiple issues occurring here. Anyway, we'll track down as many of these problems as we can.

- Oshyan


My comment is from noticing that when these crashes do happen (that won't be replicated by the actual input, such as redoing what you were doing from recovering from the crash), the preview will say "Aborting threads..." and that's the last sight from TG before CTD, so there may be some correlation there since the user changes aren't doing it in any replication.

I'm sure if I wasn't lazy and checked the Windows logs after these events it would likely be something about an uncaught/unhandled exception, which of course, will kill the thread. Often the way Windows handles this, is killing the host process handling it if it's not explicitly through another executable.

I may be wrong, here, but I am am not sure there is much thread handling for a good portion of TGs node network that would cause a crash other than the GUI, and Preview and maybe some calculations for objects. Not positive but may be the case considering the XML nature of the network/file system and what the preview/renderer reads from.
Check out my Terragen Discord: https://discord.gg/Vy5FRTE