|
Jochen Stier
|
 |
« Reply #3 on: February 28, 2009, 11:24:54 PM » |
|
Ok, I see what you are looking for. When you select a transform in the treeview, you can already see a similar input field at the bottom of the editor window. Although it is not working properly yet, you can enter values by hand, but that still needs some work. I have tried a different approach with Geist3d by using these 3D manipulators, i.e. the green box the surrounds the object. I have first seen this with the OpenInventor scene graph library years back. It is probably not as effective as the multiple windows you have in Blender, 3D Max or XSI, where each window snaps an object to one of the main axis, but the manipulators allow you to position objects wherever you currently are in the scene. It kind of reverses the concept; instead of positioning along an axis in each window you choose the axis by clicking on proper face of the manipulator. The advantage is that you are taking the coordinate system with you wherever you are. In these large environments that seemed the right way to go. I have also added a snap to grid function which seemed quite useful. So, when you design your system, think of a smallest unit by which you can position objects. Then you can define the grid to just snap things into place with the manipulator.
Ultimately we have two different problems here. The first is to design the model, let’s say a space ship and then import it into Geist3D and specify different locations where you can add weapons, cargo hold, life pod etc. The other problem is to then to allow a player to fill the place holders with whatever objects they choose. My plan is to program different classes of ships, for example, a frigate. All I need to know is how many different slots it has and what they are named. As the artist, you can then design the ship and position the slots wherever you want them to be. That happens in Geist3D using different transform nodes. But they have to be named properly. Then we export the model as a .3do file. The graphics engine will then simply know, because it’s of class frigate, that it has to look for x number of slots. We can then use Lua script to say, slot n has this object attached to it. This way, another game developer, who only knows Lua and the workings of the editor, can then use the 2D Gui widgets in Geist3D to build a store, or marketplace where you can purchase stuff for your frigate. It’s a thin balance between the Lua based functionality, which anyone should be able to do, and the actually hard coded stuff which only a developer can do. I am not quite sure how to separate these concerns, but it will be quite important to do it right….
Another reason to program the different classes right inside the engine is to have better control about the physical dynamics of the objects. Some classes of ships, like very large space station, will also have an inside area where you can walk around in. Although that has already been demonstrated with Eco Bora Delta, each station, or type of station, may need additional logic that just has to be programmed out in native code.
He Tamarin you are just around the corner. If you ever have some time, we can get together and do some brainstorming…
On another note, I just finished the multithreading code that will allow several threads to compute the planet surface at once. Right now I only had one thread doing it, but since I have a dual core processor, I knew that I could squeeze out more performance out of my system. I realize now that in the future, when we have true parallel processors on the CPU, it will be possible to create absolutely stunning planets with all the variations of our own planet. Unfortunately, it will be quite some time until enough people have such powerful computers before a game along those lines will become viable.
|
