TG2 enhancements and fixes

Started by commorancy, March 08, 2009, 03:41:25 AM

Previous topic - Next topic

commorancy

1) When Terragen 2 crashes, the recent documents area becomes empty.. it should always store the most recent documents crash or not. Needs to be fixed
2) ctrl-r to render using the default set renderer (standard on nearly every other rendering product out there)... or the ability for user settable hotkeys
3) F3 and F4 should render using the renderers actually defined in the renderers area
4) Edit->Delete does not work to delete objects.  You have to actually press the delete key.  Needs to be fixed.
5) When dragging the viewport around to find a camera angle, the screen redraws very slowly unless the pause button is pressed before moving around.  The preview renderer should autopause to increase viewport dragging performance until the mouse is released.
6) Support for objects with more than 16 shaders.. or alternatively, a smart import system that will break down a complex object into multiple objects each with up to 16 shaders.
7) An actual error handling system so that instead of TG2 simply just crashing, that it a) crashes and then sends you a report or b) crashes, but the error handler at least lets you save your current scene before closing and tries to do some graceful cleanup before completely closing.
8) When a sun is behind an opaque object with glow-in-atmosphere turned on, the glow can be seen in front of the opaque object.  All opaque objects should obscure the glow (or at least substantially reduce it).

Please let me know if there are any fixes or workarounds for any of these issues.

Thanks.



Seth

QuoteWhen a sun is behind an opaque object with glow-in-atmosphere turned on, the glow can be seen in front of the opaque object.  All opaque objects should obscure the glow (or at least substantially reduce it).


I think "enable ray traced shadows" (in atmo tab) take care of that error

reck

Yes I believe RTS does stop this problem but it increase render time a lot, so it's not really a good "fix".

Seth

...
without RTS => bug
with RTS => no bug
maybe you think it's not good but it's defintely a solution.

jo

Hi,

Quote from: commorancy on March 08, 2009, 03:41:25 AM
1) When Terragen 2 crashes, the recent documents area becomes empty.. it should always store the most recent documents crash or not. Needs to be fixed
It's not a bug, it's deliberately done that way to avoid issues with it getting messed up in the case of a crash. Can't remember exactly why right now, but there was a good reason for it. Basically it loads the recent files at startup and writes them during the proper shutdown process. TG2 shouldn't crash (no, really) then it wouldn't be a problem.

Quote2) ctrl-r to render using the default set renderer (standard on nearly every other rendering product out there)...
The current unreleased build does this now.

Quoteor the ability for user settable hotkeys
We talked about this when I added the input binding customisation, but decided to leave it for the future. It's not essential, there's quite a bit of work and there are some issues with it to be worked out. It'll probably happen eventually.

Quote3) F3 and F4 should render using the renderers actually defined in the renderers area
F3 and F4 ( on Windows ) are simply hotkeys to open the Render window or the 3D Preview in the main window if it happens to closed. It has nothing to do with renderers.

Quote4) Edit->Delete does not work to delete objects.  You have to actually press the delete key.  Needs to be fixed.
Do you mean in the lists in the upper left? They don't actually support any of the edit commands, but I suppose it would be fair enough to add support for delete. It works in the network view.

Quote5) When dragging the viewport around to find a camera angle, the screen redraws very slowly unless the pause button is pressed before moving around.  The preview renderer should autopause to increase viewport dragging performance until the mouse is released.
I don't have any problems with this myself, I don't see what you mean.

Quote6) Support for objects with more than 16 shaders.. or alternatively, a smart import system that will break down a complex object into multiple objects each with up to 16 shaders.
We may have news regarding this, I'm not sure myself so nobody get excited just yet.

Quote7) An actual error handling system so that instead of TG2 simply just crashing, that it a) crashes and then sends you a report or b) crashes, but the error handler at least lets you save your current scene before closing and tries to do some graceful cleanup before completely closing.
In the situations TG2 actually crashes things have gone pretty badly wrong. It's by no means certain that anything useful could be retrieved. If you want to keep things current then save before you render, just hit Ctrl-S, it isn't hard. Maybe we could add a preference to automatically save prior to rendering.

TG2 is much better than it was at catching problems during rendering that previously would have caused crashes.

Regards,

Jo

commorancy

Quote from: jo on March 08, 2009, 06:33:51 AM
(Recent Documents Missing After Crash is) not a bug, it's deliberately done that way to avoid issues with it getting messed up in the case of a crash. Can't remember exactly why right now, but there was a good reason for it. Basically it loads the recent files at startup and writes them during the proper shutdown process. TG2 shouldn't crash (no, really) then it wouldn't be a problem.

Perhaps there was a good reason for this.  However, here's a way to deal with this issue.  Use a file saved on the filesystem (or even the registry if you like).  If TG2 closes properly, it's updated.  If TG2 crashes, no problem.. the previous recent docs are still listed there (the old ones).  I'd prefer to at least have it load up the previous documents (without the most recently saved) than nothing.  I use the recently saved documents as a history to go back to as reference.  When they're in the list in order, I know which one is which.  When it's dumped, I have to assume the file last modified value in Windows is accurate... and that assumes they were all saved to the same location (which doesn't always happen).  The only problem would be if the Recent Documents saved doc gets corrupted because it crashes while saving this doc.  Worst case, it's corrupted and it needs to be deleted... in this case, a file would be better than the registry.

As far as crashing.. we'll come to that issue shortly..

Quote from: joWe talked about this when I added the input binding customisation

Not necessary since you will be supporting ctrl-r (at least for me)

Quote from: joF3 and F4 ( on Windows ) are simply hotkeys to open the Render window or the 3D Preview in the main window if it happens to closed. It has nothing to do with renderers.

Ok, I misunderstood what these F keys were for.  Thanks for the clarification.  I was assuming that it would open and begin rendering... rather than just opening it.

Quote from: jo
Quote from: commorancy4) Edit->Delete does not work to delete objects.
Do you mean in the lists in the upper left? They don't actually support any of the edit commands, but I suppose it would be fair enough to add support for delete. It works in the network view.

In Objects, Terrain, Shaders, Water, Atmosphere, Lighting, Cameras or Renderer when you add anything new, select the object and choose Edit->Delete, TG2 does nothing.  If, however, you click the delete key on the keyboard, the object is deleted.  Edit->Delete and the delete key should function the same.

Quote from: jo
Quote from: commorancy5) When dragging the viewport around to find a camera angle, the screen redraws very slowly.
I don't have any problems with this myself, I don't see what you mean.

The performance doesn't degrade unless you add a large population (or other imported objects) and have the population show as a huge number of bounding boxes.  Then, the performance of the viewport degrades substantially when moving.  What you see is jerky movement and non-accuracy.   Pausing the preview allows you to move around in the viewport substantially faster than when not paused.  This is more pronounced when other applications on the system are also utilizing the CPUs.

Quote from: joWe may have news regarding (more than 16 shaders), I'm not sure myself so nobody get excited just yet.

Here's to hoping.

Quote from: joIn the situations TG2 actually crashes things have gone pretty badly wrong. It's by no means certain that anything useful could be retrieved. If you want to keep things current then save before you render, just hit Ctrl-S, it isn't hard. Maybe we could add a preference to automatically save prior to rendering.

TG2 is much better than it was at catching problems during rendering that previously would have caused crashes.

It's not the rendering that's the problem.  I've rarely, if ever, had TG2 crash during rendering (now that I'm on 64 bit with 8GB of RAM that is).  So, it's definitely robust during rendering.  My issue is crashing while working with the interface to create the scene.  For example, simply deleting the last camera is enough to crash TG2 (which I only just found while writing this reply).  Attaching the wrong blender to the wrong slot will crash TG2.  Creating certain interconnections in the node network will cause crashes.  These are the crashes that can wipe out 20-30 minutes of work (or more) depending on how frequently the person saves.  Basically, as long as you expose a scene programming language for users to use, there's a the real possibility that the user can create a project with a divide by zero error, a buffer overflow error or an infinite loop.  These are all errors that must be expected when creating and exposing a programming language.  So, the way around this issue is to let the users build the node network, but not actually see the results immediately.  Instead, the user should have to press a 'compile' button.  This way, you can run the language through a syntactical checker that will work through and provide immediate error feedback to the user rather than simply crashing.  It's great that TG2 implements the language live now, but the drawback is that there's no way to check for simple errors.  With infinite loops, you may not be able to check this in an interpreter or compiler.  Instead, that would have to be detected at runtime, but then you would need to give the user a way to break out of the program and get back into the editor.

However, if you segregate the programming language from the renderer program in either a separate thread or process, this can isolate crashes from the main application.  So, if the compiler or interpretor crashes as a child process, you can easily recover by passing the error up to the user.  This should also eliminate many of the programming error crashes in the node network.

These are the kinds of design changes that will make the node network system much more robust from a user perspective.

jo

Hi.

Quote from: commorancy on March 08, 2009, 07:30:39 AM
In Objects, Terrain, Shaders, Water, Atmosphere, Lighting, Cameras or Renderer when you add anything new, select the object and choose Edit->Delete, TG2 does nothing.  If, however, you click the delete key on the keyboard, the object is deleted.  Edit->Delete and the delete key should function the same.
Yes, I agree. It should be possible to support the Delete command and probably the Copy and Cut commands, athough the Paste one could be tricky. I'm not sure if Cut/Copy makes sense if you can't also paste into the lists.

QuoteThe performance doesn't degrade unless you add a large population (or other imported objects) and have the population show as a huge number of bounding boxes.  Then, the performance of the viewport degrades substantially when moving.  What you see is jerky movement and non-accuracy.   Pausing the preview allows you to move around in the viewport substantially faster than when not paused.  This is more pronounced when other applications on the system are also utilizing the CPUs.
Ah, ok. I'll look into it.

QuoteMy issue is crashing while working with the interface to create the scene.  For example, simply deleting the last camera is enough to crash TG2 (which I only just found while writing this reply).
That should be fixed in the latest unreleased build, although it hasn't been extensively tested yet.

QuoteAttaching the wrong blender to the wrong slot will crash TG2.
Do you have any examples of this which aren't due to circular paths? If crashes are happening just from connecting nodes, aside from circular paths, then it's a bug we need to fix.

QuoteCreating certain interconnections in the node network will cause crashes.
This has been fixed a couple of alpha releases ( release to private testers, not alpha as such, since the last public beta ) back.

Lots of errors can be checked dynamically. Lots of errors can also be prevented. For example if a node lets a divide by zero error propagate then it's a bug we need to fix, as generally speaking we look for those.

We have talked about a debug mode, which may be implemented at some point in the future. Things can be improved for sure, but the sort of thing you're suggesting is a fairly major amount of work. It's definitely not going to happen before the final release.

Regards,

Jo

commorancy

Quote from: joYes, I agree. It should be possible to support the Delete command and probably the Copy and Cut commands, athough the Paste one could be tricky. I'm not sure if Cut/Copy makes sense if you can't also paste into the lists.

I kind of assumed that these menus weren't connected up because of some kind of issue.  But, even if cut, copy and paste can't be easily managed, seems like delete should be reasonably easy.

Quote from: joDo you have any examples of this which aren't due to circular paths? If crashes are happening just from connecting nodes, aside from circular paths, then it's a bug we need to fix.

I'll see if I can get a list together for you.

Quote from: joWe have talked about a debug mode, which may be implemented at some point in the future. Things can be improved for sure, but the sort of thing you're suggesting is a fairly major amount of work. It's definitely not going to happen before the final release.

I realize what I'm asking (compile time checking) is a lot of work.  I'm not really asking you to put it in your present release candidate today.  This one is more of a long term suggestion.  I realize that the way it's coded now followed by moving to a compiled or interpreted system is a substantial change that requires a fairly large overhaul.  Again, just a suggestion for longer term consideration.

Thanks.

PG

Quote from: jo on March 08, 2009, 07:58:50 AM
Do you have any examples of this which aren't due to circular paths? If crashes are happening just from connecting nodes, aside from circular paths, then it's a bug we need to fix.

Sorry to hijack the thread a little bit but are there any plans to catch circular paths and stop them being formed, i.e. tracing the heirarchy and blocking a connection being made if it forms a circular path?
Figured out how to do clicky signatures

Mohawk20

Quote from: PG on March 08, 2009, 01:19:22 PM
Quote from: jo on March 08, 2009, 07:58:50 AM
Do you have any examples of this which aren't due to circular paths? If crashes are happening just from connecting nodes, aside from circular paths, then it's a bug we need to fix.

Sorry to hijack the thread a little bit but are there any plans to catch circular paths and stop them being formed, i.e. tracing the heirarchy and blocking a connection being made if it forms a circular path?

Every comment from Planetside about the coming release regarding this subject suggests they have fixed this as good as possible...
Howgh!

jo

Hi PG,

Quote from: PG on March 08, 2009, 01:19:22 PM
Sorry to hijack the thread a little bit but are there any plans to catch circular paths and stop them being formed, i.e. tracing the heirarchy and blocking a connection being made if it forms a circular path?

Yes, I did mention that was fixed above.

Regards,

Jo

commorancy

#11
Here's my list so far:

1) Turn on 'Special Tool Tips' from Preferences.  Hover over any object crosshairs in viewport and when 'special' Toolitip is supposed to appear.. crash
2) Create a sphere of radius 6.378e+006.  Then, go into the object and add a 1 to the radius so that it becomes 6.378e+0061 ... crash
3) Yes, this one is a circular reference, but I wanted to point it out anyway simply because of its accidental nature.. While working with the nodes to try and reproduce some crashes, I came across this issue.  I am working with several different function types including an 'abs scalar'.  I'm adding and removing links between various function objects and occasionally TG2 would crash.  Apparently, as I'm undoing a link from another object function, I'm apparently releasing the mouse accidentally over or near the top of the input node of the output from the same 'abs scalar'.  While I can understand circular references between several different objects might be harder to debug, TG2 should not allow me to make a circular reference between the output and the input of the same object.  When this happens, it crashes.  

Note, when working with nodes, it's very easy to accidentally unlink something and drop the mouse near the input of something else and accidentally create a circular reference unintentionally because of proximity snapping (pulls the link towards the closest input).  I believe you indicated these circular references may have been fixed in a later version.

Note.. I'm still trying to reproduce some other crashes/issues that I'd run into earlier, but I'm thinking that some of them may have been accidental circular references such as in issue 3.


Tangled-Universe

Quote from: commorancy on March 11, 2009, 10:00:13 AM

2) Create a sphere of radius 6.378e+006.  Then, go into the object and add a 1 to the radius so that it becomes 6.378e+0061 ... crash


Ehhrr....the difference between those numbers is EXTREMELY huge. It's billions and billions and billions times bigger than 6.378E+006.
There's no desktop-machine and probably not (m)any supercomputer(s) which are able to handle these kinds of numbers.

This is not a bug at all, you just made a "little" mistake :)

About #3: TG2 can still crash when you do a lot of copy/paste/duplicate/delete actions quickly after each other. This is already reported. I think your problem is of the same kind.
Regarding accidentially connecting outputs to wrong inputs because of proximity-snapping etc., I'd say: don't put your nodes to close to each other and also work systematically in a top to bottom fashion. It's better understandable and more clear too.

Martin

commorancy

#13
Quote from: Tangled-Universe on March 11, 2009, 10:16:27 AM
Quote from: commorancy on March 11, 2009, 10:00:13 AM
2) Create a sphere of radius 6.378e+006.  Then, go into the object and add a 1 to the radius so that it becomes 6.378e+0061 ... crash

Ehhrr....the difference between those numbers is EXTREMELY huge. It's billions and billions and billions times bigger than 6.378E+006.
There's no desktop-machine and probably not (m)any supercomputer(s) which are able to handle these kinds of numbers.

This is not a bug at all, you just made a "little" mistake :)

If it crashes, it's a bug.  Yes, it's billions of times bigger. Your statement also assumes that the crash is related to the size of object. If so, that means TG2 should simply detect an error when trying to allocate resources to handle it.  So, an out of memory condition should only generate an out of memory error in an exception handler and not crash.  Again, this IS a bug.  There are other reasons that could lead to a crash by putting that value into that field, such as a buffer overrun.

Of course, there is one other way to handle this... and that is to limit the the maximum radius of the object to some arbitrary amount and limit the maximum amount of digits that can be placed into that field.  This prevents excessively large numbers in the field and can avoid buffer overrun issues.  But, even if they choose to place a maximum radius onto that field, that doesn't negate the necessity of creating an exception handler to gracefully handle out of resource conditions.

Quote from: martinAbout #3: TG2 can still crash when you do a lot of copy/paste/duplicate/delete actions quickly after each other. This is already reported. I think your problem is of the same kind.
Regarding accidentially connecting outputs to wrong inputs because of proximity-snapping etc., I'd say: don't put your nodes to close to each other and also work systematically in a top to bottom fashion. It's better understandable and more clear too.

It doesn't matter how far apart or how close they are together.  The reality is, it's all based on an accidental nature.  If the snapping grabs the link and connects it accidentally, it's over.  Putting them farther apart is also only as relative as your zoom factor.  If you are heavily zoomed in, yes this issue can be reduced.   However, when you zoom out, everything is much smaller including the connection sections.  So, your suggestion here is only minimally effective at avoiding this issue.  The real fix is for TG2 to gracefully prevent circular connections whether accidental or intentional.

jo

Hi commorancy,

To address your 1, 2, 3:

1) The tooltips problem has been fixed in private releases for some time. If you look at the "More info" section of the Prefs dialog it will show you that it should be turned on unless you're using XP when you mouse over the setting.
2) We do need to address problems like this. They shouldn't cause a crash.
3) As I've said, the circular references problem is fixed. It's no longer possible to make them and you get a warning if you try to let you know why you can't make the connection.

Regards,

Jo