How does the file format relates to recovering from crashes?
Even if the crash occurs when saving a file, you should still have the .blend1 (and more) backups.
Ctrl-C in the console raises KeyboardInterrupt which will stop executing script (unless they have a general except clause).
Martin
The expression would be in ascii so you can for example open a Maya Ascii file in a text editor and adjust the expression without opening it in Maya first. I’ve done this in both Shake and Maya in order to sort crashes when opening files as they both have ascii scene descriptions. With Shake, it was for custom nodes whose inputs I’d changed and for Maya, it was for a Maya bug related to a mirrored proxy object.
When it comes to nodes (especially programmable ones), because it’s harder to account for all given scenarios, an ascii description is just the ultimate level of protection against crashes.
True, but when I’ve had to recover from a .blend1, I found that it had saved too recently. I do keep multiple copies as I go though but just being able to go into an ascii file and see the whole scene layout gives that extra peace of mind and it means not having to revert back to old data. It also means that people who suffer hard drive crashes have a much better chance of file recovery.
The other neat thing about ascii stuff is that you can easily copy and paste data from inside blender that you might not otherwise have access to. In Shake for example, you can convert audio files to IPOs and instead of writing an exporter, you just open the project file in a text editor and copy/paste the data out.
The Mac version doesn’t run with a console by default. Running it manually in a console does give you that functionality though.
Interesting osxrules,
couldn’t any crash Python related be investigated if we take care of saving the Python files we use? I am not absolutely sure for PyDrivers: can we call a script through them (would free us from the one liner…)
Jean
Any text in a blend file is ascii encoded and completely editable with a competent editor (vi, emacs, pico would probably work too), just make sure you keep the same number of characters (overwriting with spaces is safest).
You can also open a fresh blend file, append the offending scene and remove the offending object using the outliner without switching to the scene.
If you save often, it would probably help if you increased the number of old backups. (User Prefs: Auto Save: Save Versions)
Text files usually means longer save/load time, so it’s a tradeoff.
Yes, a text based version of SDNA might be nice, but nobody has the time to do it.
Only the windows version uses a console by default, AFAIK.
Martin
<REMOVED> (Wrong thread!)
[quote=“IamInnocent,post:23,topic:406325"”]
Interesting osxrules,
couldn’t any crash Python related be investigated if we take care of saving the Python files we use? I am not absolutely sure for PyDrivers: can we call a script through them (would free us from the one liner…)
[/quote]
External Python files are ok but they aren’t as convenient to use (hence the thread I imagine) as you have to go outside of Blender and make one for each event you want to script.
There could be something like I used in my 3delight export script for animating shader input values. You basically have a set of text fields and if you enter something like $bounce into the field, it does a lookup of a single python file which just has a set of conditions to check the variable name and you can enter any kind of Python expression including function calls etc. I’ve even used it to do data file lookups from Shake, which is handy.
You don’t need to rerun the main script either as it uses an execfile call in an exception block. When the code executes, the input value is just the result of the expression.
Pydrivers could be the same - just have a single word lookup in a .py file full of conditions where the Blender variables are passed by passing the global namespace. It could perhaps look for the file in the same directory as the .blend so you remember to take it with you if you copy your files to another machine (this is really the main advantage of internal scripts btw).
This has an advantage over internal expressions in that you can share functions between Pydrivers and you can have pretty long expressions. It also keeps the interface cleaner.
In fact, there could just be one single internal file that has the set of conditions and this file loads into the text editor. This way you can see all your Pydriver expressions at the same time (handy for reducing any redundancy). This could even be used for animating every single variable inside Blender.
You would just display the expression file that contained all of the expressions and you would simply add a new entry like this:
time = Blender.Get(‘curframe’)
if var == $bounce:
> height = cos(time)
> return height
elif var == $flicker:
> brightness = noise(time)
> return brightness
In the Blender interface, all you’d do to make a light flicker is simply add the word $flicker in the brightness field instead of a value.
There could even be an option to see an IPO of the expression to check for discontinuity. The calculation would be limited to the global frame range as it would have to work out the expression for every frame.
Shake uses the one-liner idea too and it’s ok for small expressions but for long nested expressions, it gets quite unreadable. One way they improve it is by allowing arbitrary variables so if you are referencing MultiPlane3.Camera_001.TranslationX or something, you can make a local variable called x and make it the above value. Then when you make an expression, you can use the local variable x. It still doesn’t solve the issue entirely but it does reduce clutter in some cases and it helps if you use the same long variable in multiple fields.
Of course, I forgot about that. Shake has that feature too and it helps recover from crashes - I actually use that feature more than any other for recovery. I guess you can edit the appended scene from a script or by editing as long as it doesn’t load whatever fault there may be.
Yeah ascii files do take a bit longer but it’s not noticeable on modern computers. Scenes under 10MB will save in under a second. But it would take some time to implement it and it would need updated regularly.
I think it would probably be a better idea to make a Maya Ascii import/export script and that way kill two birds with one stone. I think a .ma file will support generic data as it would need to save Maya’s custom plugin data so it might be generic enough to support all of Blender’s options. But that would likely go unused as a save format. Again, time is the issue though.
fbx seems ok but again there are limitations that prevent it being used as an ascii save format.
I’d agree that it’s not really a necessary feature, it has advantages but the time required could certainly be better spent on more important things.
All right,
I re-read this and it is still way over my head and I can’t really understand it but one day I will! Hopefully you still have long to live since it may not be for tomorrow.
Regards
Jean