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: joQuote 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: joQuote 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.