...
by Redacted · in Artist Corner · 02/04/2007 (4:37 pm) · 100 replies
...
#23
While it does offer advantages, I'd hate to require the extra setup work when separate scenes for each animation aren't required to solve some specific problem/short coming.
I suppose a lot of the extra setup work could be automated, i.e. have some python code that manufactures the scenes, perhaps based on some sort of setup in the UI that associated actions/ipos with objects in the export tree.
02/12/2007 (1:43 pm)
Oops, I forgot to comment on the scenes and animations.While it does offer advantages, I'd hate to require the extra setup work when separate scenes for each animation aren't required to solve some specific problem/short coming.
I suppose a lot of the extra setup work could be automated, i.e. have some python code that manufactures the scenes, perhaps based on some sort of setup in the UI that associated actions/ipos with objects in the export tree.
#24
- Empty (obvious)
- Link Objects (objects in the current scene will be directly linked in the new scene)
- Link ObData (objects in the current scene will be duplicated into the new scene, though linked to the same datablocks)
- Full Copy (objects and associated datablocks in the current scene will be duplicated into the new scene)
So in essence it wouldn't be that hard to set up for animation, provided of course the user has finalized which objects are going to be present before creating all the separate scenes for animation. Note though that in order for IPO's & NLA's to be unique, you need to at least choose option 3.
Alternatively of course, one could try the classical method of defining frame ranges for each animation.
02/13/2007 (5:02 am)
Note that when creating a new scene, the user is presented with several options:- Empty (obvious)
- Link Objects (objects in the current scene will be directly linked in the new scene)
- Link ObData (objects in the current scene will be duplicated into the new scene, though linked to the same datablocks)
- Full Copy (objects and associated datablocks in the current scene will be duplicated into the new scene)
So in essence it wouldn't be that hard to set up for animation, provided of course the user has finalized which objects are going to be present before creating all the separate scenes for animation. Note though that in order for IPO's & NLA's to be unique, you need to at least choose option 3.
Alternatively of course, one could try the classical method of defining frame ranges for each animation.
#25
If we're just trying to deal with frame ranges, why not just add those input variables to the sequence panel ?
If we're dealing with non-action IPOs, why not just have a panel that allows for specifying a relationship between the IPO and the object it affects ?
With all of those scenes, how does the exporter know which objects are copies and should only be exported once ? How does the exporter know which objects are new and should be exported ?
Maybe separate scenes is the correct way to move forward, but before this type of change is committed to, I think we need to more completely sort out the benefits it provides, the problems we might run into and how it will actually work from the user's perspective.
02/13/2007 (10:18 am)
Ok, maybe I'm just having a dense moment, but I have to ask what problem or set of problems is solved by having the multiple scenes ?If we're just trying to deal with frame ranges, why not just add those input variables to the sequence panel ?
If we're dealing with non-action IPOs, why not just have a panel that allows for specifying a relationship between the IPO and the object it affects ?
With all of those scenes, how does the exporter know which objects are copies and should only be exported once ? How does the exporter know which objects are new and should be exported ?
Maybe separate scenes is the correct way to move forward, but before this type of change is committed to, I think we need to more completely sort out the benefits it provides, the problems we might run into and how it will actually work from the user's perspective.
#27
Bah! Artists have nothing better to do, :-). Just kidding of course.
Looking at the .blend file from the link, I notice that all of the IPOs associated with the individual bricks (those that I looked at anyway) had the same name as the object. I'm not sure how far that default naming gets us.
Normally though, I'd assume we'd be calling Object.getIpo() to get the IPO associated with a brick like this.
No, I just tested this with 2.42. Scene->Add New->Full Copy. Renaming the default cube mesh in the new scene from Cube.001 to Cube renames the default cube mesh in the old scene to Cube.001. Renaming the default cube object in the new scene from Cube.001 to Cube doesn't work. I doubt this has changed in 2.43.
I don't know, I'm not sure that multiple scenes buys us much. How can you know that Skeleton in Scene.001 and Skelenton.001 in Scene.002 are the same or different ? How would you decide to export or not export them, assuming the exporter works on all scenes in a batch mode of sorts ? How can you know which of the 244 bricks in Scene.001 correlate to which of the 244 bricks in Scene.002 ? Don't the sequences have some dependence on the TGE node names being generated so we have to have this correlation ? I'm assuming we want to create one house with several animations and not an exploding house that looks exactly the same as a bulldozed house.
Lets say the artist who created the exploding house wanted an exploding animation and an animation showing the house being bulldozed. Lets say the exporter was modified to do what is necessary to export the sequences for the mesh objects based on the IPOs associated with them, probably similar to the python script you wrote for the artist.
One way for a user to deal with these multiple animations would be separate .blend files. The simplest method would be to make the house in one house4.blend file and then copy that to house4-exploding.blend and house4-bulldoze.blend and then animate the house. Use the exporter to export the mesh objects and animation in one of the files and then only the animation in the second file. Names of everything are preserved with this method.
An alternative method would be to make the house4.blend file and then within that file make multiple scenes, either with Full Copy or Link ObjData. I would leave the house without animations in the first scene and add one scene for each animation. Export the meshes from the first scene, switch scenes and export the first animation then repeat for the second animation.
The problem that has to be solved with this second method though is the naming of all those bricks as making a new scene via either method above causes new blender Objects to be created with new names. The Link ObjData method preserves the names of the mesh data objects though as scenes created this way share data, but have new objects.
At the moment, I don't know how one might solve this naming problem, either from a user's or a programmers perspective.
The only real draw back to the first method I mention is the multiple .blend files and by default the fact that the model isn't linked to the files. Meaning that if changes are made to the model, they aren't pushed to the dependent .blend files. This can however be somewhat reasonably solved by importing the objects via linking (Shift-F1, click the Link button) before you animate the model. Then most changes will propogate from the original house4.blend to the dependent .blend files.
02/13/2007 (11:48 am)
Quote:Since there are 214 separate meshes in the scene it would take some time to go through and specify that each one should be exported along with it's IPO.
Bah! Artists have nothing better to do, :-). Just kidding of course.
Looking at the .blend file from the link, I notice that all of the IPOs associated with the individual bricks (those that I looked at anyway) had the same name as the object. I'm not sure how far that default naming gets us.
Normally though, I'd assume we'd be calling Object.getIpo() to get the IPO associated with a brick like this.
Quote: Is it possible to have objects in different scenes with the same names?
No, I just tested this with 2.42. Scene->Add New->Full Copy. Renaming the default cube mesh in the new scene from Cube.001 to Cube renames the default cube mesh in the old scene to Cube.001. Renaming the default cube object in the new scene from Cube.001 to Cube doesn't work. I doubt this has changed in 2.43.
I don't know, I'm not sure that multiple scenes buys us much. How can you know that Skeleton in Scene.001 and Skelenton.001 in Scene.002 are the same or different ? How would you decide to export or not export them, assuming the exporter works on all scenes in a batch mode of sorts ? How can you know which of the 244 bricks in Scene.001 correlate to which of the 244 bricks in Scene.002 ? Don't the sequences have some dependence on the TGE node names being generated so we have to have this correlation ? I'm assuming we want to create one house with several animations and not an exploding house that looks exactly the same as a bulldozed house.
Lets say the artist who created the exploding house wanted an exploding animation and an animation showing the house being bulldozed. Lets say the exporter was modified to do what is necessary to export the sequences for the mesh objects based on the IPOs associated with them, probably similar to the python script you wrote for the artist.
One way for a user to deal with these multiple animations would be separate .blend files. The simplest method would be to make the house in one house4.blend file and then copy that to house4-exploding.blend and house4-bulldoze.blend and then animate the house. Use the exporter to export the mesh objects and animation in one of the files and then only the animation in the second file. Names of everything are preserved with this method.
An alternative method would be to make the house4.blend file and then within that file make multiple scenes, either with Full Copy or Link ObjData. I would leave the house without animations in the first scene and add one scene for each animation. Export the meshes from the first scene, switch scenes and export the first animation then repeat for the second animation.
The problem that has to be solved with this second method though is the naming of all those bricks as making a new scene via either method above causes new blender Objects to be created with new names. The Link ObjData method preserves the names of the mesh data objects though as scenes created this way share data, but have new objects.
At the moment, I don't know how one might solve this naming problem, either from a user's or a programmers perspective.
The only real draw back to the first method I mention is the multiple .blend files and by default the fact that the model isn't linked to the files. Meaning that if changes are made to the model, they aren't pushed to the dependent .blend files. This can however be somewhat reasonably solved by importing the objects via linking (Shift-F1, click the Link button) before you animate the model. Then most changes will propogate from the original house4.blend to the dependent .blend files.
#28
A scene appears to be a separate copy of all the data, but see it more like an abstration of a set of layers. No, you may not have a Skeleton in Scene 1 and another object called Skeleton in Scene 2. If you tried to rename the object in Scene 2 to Skeleton, Blender would assign it the name Skeleton.001.
IMHO, using separate scenes would be a serious undertaking for all involved. Yes, you'd be able to use the 214 separate meshes in that one example as you said. That is an extreme example, though. It would be better to come up with some script just for that one case, or a generalized set of utilities; not change the whole exporter. For me, I don't have more than two or three (including col) meshes in a scene (unless playing with the DIF exporter, but then there are no IPOs).
Is all this confusion coming from the need to add FPS? If so, then add a popup or another tab button and be done with it. Could you widen the exporter to have two columns of buttons, instead of just the one? It'd make more sense to redesign the existing GUI than it would to change the underlaying framework.
02/13/2007 (11:49 am)
@Joseph:A scene appears to be a separate copy of all the data, but see it more like an abstration of a set of layers. No, you may not have a Skeleton in Scene 1 and another object called Skeleton in Scene 2. If you tried to rename the object in Scene 2 to Skeleton, Blender would assign it the name Skeleton.001.
IMHO, using separate scenes would be a serious undertaking for all involved. Yes, you'd be able to use the 214 separate meshes in that one example as you said. That is an extreme example, though. It would be better to come up with some script just for that one case, or a generalized set of utilities; not change the whole exporter. For me, I don't have more than two or three (including col) meshes in a scene (unless playing with the DIF exporter, but then there are no IPOs).
Is all this confusion coming from the need to add FPS? If so, then add a popup or another tab button and be done with it. Could you widen the exporter to have two columns of buttons, instead of just the one? It'd make more sense to redesign the existing GUI than it would to change the underlaying framework.
#30
Off the top of my head, use the name of the object's datablock.
@Scott
Not at all. Its merely a proposal for future development.
--
Any more ideas in the idea bank, anyone?
02/13/2007 (1:14 pm)
@JosephQuote:
I have no idea offhand how to solve the naming problem without introducing a naming convention to correlate the objects in one scene with the objects in another
Off the top of my head, use the name of the object's datablock.
@Scott
Quote:
Is all this confusion coming from the need to add FPS?
Not at all. Its merely a proposal for future development.
--
Any more ideas in the idea bank, anyone?
#32
It'd be relatively trivial to automate this from a management panel of sorts. One could have a set of buttons that would allow the user to set all selected objects to exportable, set the detail level etc. In fact, this might help in situations where it isn't possible or is simply awkward to deal with the current parenting in place now, i.e. the Shape->Detail32->etc. This is the way the Blender2Crystal exporter works, or did last time I used it a year or so ago.
Again, I think it is very important here that we define what problem or set of problems we're trying to solve. I'm not sure that Dan Keller's house requires a scene mode to make it work. I think the house just requires a mode in the exporter that exports object IPOs somehow.
I think all, or at least most, of what James mentions in his Scene Mode export could be supported if we tagged, say via the game properties, those objects as exportable. Of course, I'm assuming someone has written or will write the python code necessary to make sense of the data in blender to export it properly. Combining this with library objects (Shift-F1, Link button) or just copying files (cp house4.blend house4-exploding.blend) or even separate scenes within blender (of which the exporter would remain oblivious) should work here.
Some of this does boil down to training users how to mess with these things. Its likely we'd want to create some more cookbooks, tutorials or automated ways of doing as much of this as we can.
Are there other future things the exporter needs to support ? Maybe my house of cards falls when other things come into play, :-).
02/13/2007 (8:43 pm)
Why don't we use the game properties ? Select an object in blender and press F4. In the lower left, you can manually add several types (boolean, float, etc.) of properties to an object. These properties are also available via the python API (Object.getProperty(), Object.addProperty(), Object.removeProperty() and the Property class).It'd be relatively trivial to automate this from a management panel of sorts. One could have a set of buttons that would allow the user to set all selected objects to exportable, set the detail level etc. In fact, this might help in situations where it isn't possible or is simply awkward to deal with the current parenting in place now, i.e. the Shape->Detail32->etc. This is the way the Blender2Crystal exporter works, or did last time I used it a year or so ago.
Again, I think it is very important here that we define what problem or set of problems we're trying to solve. I'm not sure that Dan Keller's house requires a scene mode to make it work. I think the house just requires a mode in the exporter that exports object IPOs somehow.
I think all, or at least most, of what James mentions in his Scene Mode export could be supported if we tagged, say via the game properties, those objects as exportable. Of course, I'm assuming someone has written or will write the python code necessary to make sense of the data in blender to export it properly. Combining this with library objects (Shift-F1, Link button) or just copying files (cp house4.blend house4-exploding.blend) or even separate scenes within blender (of which the exporter would remain oblivious) should work here.
Some of this does boil down to training users how to mess with these things. Its likely we'd want to create some more cookbooks, tutorials or automated ways of doing as much of this as we can.
Are there other future things the exporter needs to support ? Maybe my house of cards falls when other things come into play, :-).
#34
I'm not necessarily proposing to switch from the Shape/Empty tree used now to game properties, certainly not just to do it. I was trying to figure out what problem(s) might be being solved with the multiple scene and other scenarios discussed and alternatives to solving that/those problem(s). I do however believe a non-Empty tree based method, such as one using Game Properties, would be easier for first time users, especially novice blender users.
Not within blender itself that I can see off hand. The outliner doesn't support query/display based on game properties, nor do I see a way for it to display game properties.
Probably not as a side effect, intended or not, based on the ordering of the objects, since it doesn't directly provide a tree or other ordering mechanism. It'd be pretty trivial though to have an Int, Float or String game property that could influence this.
02/14/2007 (5:32 pm)
Quote:I'm not opposed to using the game properties instead of parenting to empties....
I'm not necessarily proposing to switch from the Shape/Empty tree used now to game properties, certainly not just to do it. I was trying to figure out what problem(s) might be being solved with the multiple scene and other scenarios discussed and alternatives to solving that/those problem(s). I do however believe a non-Empty tree based method, such as one using Game Properties, would be easier for first time users, especially novice blender users.
Quote:1. Can we see the properties at a glance somewhere without having to click through each object? Currently the outliner window makes it easy to see how the shape is set up.
Not within blender itself that I can see off hand. The outliner doesn't support query/display based on game properties, nor do I see a way for it to display game properties.
Quote:2. Using this method, will we be able to control the drawing order of translucent meshes as we can with the current hierarchy-based setup?
Probably not as a side effect, intended or not, based on the ordering of the objects, since it doesn't directly provide a tree or other ordering mechanism. It'd be pretty trivial though to have an Int, Float or String game property that could influence this.
#38
02/15/2007 (7:31 pm)
You know I was kidding, right?
#40
Currently, my method is as follows. I setup everything, hit the select button in the general tab, find my folder that I export everything too, locate my folder and copy/paste that location into the filepath bar, export, switch back to 3D view and save the .blend so that it remembers the folder I exported too, then go into the folder my .blend is in and review/delete the log file. It's also possible I'm using the select button wrong but it never seems to accept the folder I choose, and copy/paste is the only way I can get it to work.
If it's possible to script a set default feature it seems to me that there's room to add this "Set Default" button where the "Select.." and "Default" button are found in the General tab. It'd also be helpful if the log file went to that same folder, instead of the folder the .blend is in. In the grand scheme of things this is a very small issue compared to what's being discussed but it would sure make my life easier.
P.S. Thanks for all the hard work on this great tool and if it helps at all, I'm using Blender RC2 with the 0.94 exporter
02/15/2007 (7:55 pm)
As an end user to this great exporter I'd say that the most recent picture is my favorite option so far even if it were to take up more screen size. If you're taking suggestions, one thing I'd like to see is some sort of way to setup a default folder to export everything into, so that if I were to make a new model, and export to dts, my custom default folder would show up first instead of the path that the blender file is in. Once the model was exported then all the files would go to that folder. Currently, my method is as follows. I setup everything, hit the select button in the general tab, find my folder that I export everything too, locate my folder and copy/paste that location into the filepath bar, export, switch back to 3D view and save the .blend so that it remembers the folder I exported too, then go into the folder my .blend is in and review/delete the log file. It's also possible I'm using the select button wrong but it never seems to accept the folder I choose, and copy/paste is the only way I can get it to work.
If it's possible to script a set default feature it seems to me that there's room to add this "Set Default" button where the "Select.." and "Default" button are found in the General tab. It'd also be helpful if the log file went to that same folder, instead of the folder the .blend is in. In the grand scheme of things this is a very small issue compared to what's being discussed but it would sure make my life easier.
P.S. Thanks for all the hard work on this great tool and if it helps at all, I'm using Blender RC2 with the 0.94 exporter
Torque Owner Todd "zaz" Koeckeritz
I agree with this in principal .... however ....
having a second row of buttons was exactly what we were trying to avoid.
I offered the drop down list idea to Joseph when he was asking me about ideas on how to deal with adding more "tabs" above without burning up lots of screen real estate.
Normally I wouldn't pick a drop down list to do this as I believe it hides options from the users and is a relatively non-standard way of doing things. Both of these issues leads to making it harder for users, especially new ones, to work with the software.
If we are only adding one, or maybe two more panels to the UI and could keep the row of buttons/tabs to one row, I'd tend to stay with the buttons/tabs. If its desireable to either make the UI smaller or to add enough panels that the buttons/tabs would require more than one row, I'd be very supportive of a drop down list or other solution that eliminated multiple rows of buttons/tabs.
The real advantage of the drop down list is that it is very extensible in the number of panels one drop down can support and I think most of the users, especially if we had the Intro panel discussed above, would catch on to it real fast.
I'm just trying to provide the context of the discussion I had with Joseph when this idea came into being. It doesn't matter much to me one way or another, other than the context I provide above. No one is stepping on my toes if the drop down isn't used, :-).