Important Issues for 0.20

Jan 29, 2008 at 6:44 PM
Once LordIkon's gamepad code is finalized and committed to the source tree, we will essentially have our 0.19 release. Hence we need to start looking towards our primary goals for 0.20. We can all go into the Issue Tracker and look at what's proposed, but I feel it's important for us to take some time and discuss what's really important going forward.

For me, the important issues are as follows, in no particular order:
  • Xbox Builds. I want to get the Xbox projects to compile and run again. We've concluded that we can't really support any Xbox builds, but I firmly believe we should at least provide them. And let's be honest, that's one of the main reasons for using XNA.
  • JigLibX Physics Implementation. This goes hand-in-hand with the Xbox builds above, since we can't write a PhysX wrapper on Xbox. Also, I'm sure some people find the dependency on the PhysX system software to be a stumbling block, so this will give them another option. However, performance is a huge issue here.
  • Final SceneManager Design. I can't stress this enough. We need to flesh this out and get working on it, or else no-one will be able to do anything with the engine.
  • Game-Code Abstractions. Although this goes along with scripting, it's important that we make some effort of deciding how game code interacts with the engine. I believe we all know how much of a mess this is at the moment in QuickStartSampleGame. This includes mapping engine messages to mutable state (i.e. InputMapper) and the game-level representations of entities in the world.

Basically, when 0.20 is released, I would like to be able to start a new project, reference the appropriate assemblies, and be able to quickly put together a small world that includes a primitive landscape and a player camera, and be able to place (programmatically at first) simple entities in the world, like boxes and spheres, and have them react to the player. Hell, even a third-person camera with the player being a capsule would be a great start.

To be honest, I'm not even sure 0.19 should be a public release, or at least not a publicized one.
Coordinator
Jan 29, 2008 at 7:17 PM
I agree with everything said there. I believe for 0.19 we should release it, and make it visible, but leave 0.182b as the primary link (the one that comes up by default). Once the new engine is easier to use and/or has more capabilities, then we should make a new version the default.
Jan 30, 2008 at 2:13 AM
Edited Jan 30, 2008 at 2:14 AM
I have a good start on the JigLibX implementation. Once the Activator.CreateInstance issue is tackled, I should be able to start putting together an Xbox build. Performance isn't too bad. Pushing all of the physics to a second thread gives me about 50% of the performance of the PhysX implementation. Not good, but usable.

LordIkon, I still need a nice way to get at the terrain data. Right now I'm using the Terrain.heightData array to build the height field, but I think that's part of the problem with the boxes sometimes going below the terrain. heightData seems to store the bitmap data (n x n), i.e. the centers of the terrain quads. What I need is the rendered geometry ((n+1) x (n+1)). I either need to pull this out of the vertex buffer, or have you provide it in some terrain physics initialization method.
Jan 30, 2008 at 2:53 AM
Edited Jan 30, 2008 at 2:57 AM
Sturm, I just uploaded a patch with a custom Activator.CreateInstance replacement for BaseManagers. There's a new QSActivator static class that allows instantiation of any type, assuming a constructor that takes a QSGame parameter. I don't know why I didn't think about using Reflection earlier.

I haven't had a chance to test the Xbox build, but it compiles now at least. So barring any NotImplemented exceptions, we should be good without the BaseManger rework. I'll try to get some Xbox testing in soon, now that I have a working JigLibX implementation.

Also, the Conditional attribute is not going to work in Program.cs. It was a nice idea, but the attribute doesn't provide compile-time pre-processing. The whole reason for that code to be Windows-only was because those properties don't exist on Xbox and cause a compiler error. We're going to have to go back to the tried and true #ifdef. :)

This is all 0.20 stuff by the way, just looking for your feedback.
Jan 30, 2008 at 3:30 AM
Well, the Xbox build is confirmed working! With 100 boxes on the terrain (standard grid pattern), I get about 20 FPS while falling and about 5 FPS when colliding with the ground. Not great, but its a start! Honestly, it's better than I expected. I really need the gamepad controls though. Swapping the keyboard back and forth isn't much fun! I want to wait until the gamepad code is in the source tree, though.

Few notes:
  • The configuration XML stuff is working fine with the QSActivator replacement.
  • We need to decide how to handle the configuration XML file across platforms. Do we have one XML file per platform, or share an XML file and add sections/attributes to specify what gets loaded for which platform?
  • Garbage, garbage, garbage! We're getting 3 GCs per second, running 40-70 ms out of every second.

I'm just happy it's working!
Jan 30, 2008 at 3:35 AM
Update: I was playing around with thread affinities, and I got it up to 60 FPS on free-fall and 15 FPS on contact by giving physics it's own core.

LordIkon, we really need to push the terrain processing to a content pipeline process. It literally takes 30-45 seconds to get through the terrain setup on Xbox.
Coordinator
Jan 30, 2008 at 5:06 AM
Edited Jan 30, 2008 at 5:09 AM


shawmishrak wrote:
I have a good start on the JigLibX implementation. Once the Activator.CreateInstance issue is tackled, I should be able to start putting together an Xbox build. Performance isn't too bad. Pushing all of the physics to a second thread gives me about 50% of the performance of the PhysX implementation. Not good, but usable.

LordIkon, I still need a nice way to get at the terrain data. Right now I'm using the Terrain.heightData array to build the height field, but I think that's part of the problem with the boxes sometimes going below the terrain. heightData seems to store the bitmap data (n x n), i.e. the centers of the terrain quads. What I need is the rendered geometry ((n+1) x (n+1)). I either need to pull this out of the vertex buffer, or have you provide it in some terrain physics initialization method.


The vertices themselves should be setup in an (n + 1). "Should" be is the key phrase there, because I just realized that somehow I went back to a (n) setup over the last 6 months. It must be when I went to the terrain patch setup. I used to use a n + 1 setup, so a 4x4 image would give you 25 vertices, 5x5, which when connected ends up looking like 4 quads. If you'd like to have n + 1 x n + 1 geometry I might be able to give you the heights at each corner of a pixel in the bitmap itself. However, the corner of each pixel would need to be an average of the pixels around it which would cause the borders to look odd. Finally, we could change the entire terrain system to require bitmaps of power-of-two + 1 width and height. I'm pretty tired so maybe I am forgetting a better way.

I believe putting the terrain into the content pipeline can be put into a task for 0.20. If this is the case I believe that the camera changes and terrain changes planned will take me 2-3 months alone. Especially if we truly want to support terrains that are not "square", because I've never done anything like it, it may be a simple change, it may require rewriting huge portions.
Coordinator
Jan 30, 2008 at 5:10 AM


shawmishrak wrote:
  • Garbage, garbage, garbage! We're getting 3 GCs per second, running 40-70 ms out of every second.


What is producing the garbage?
Jan 30, 2008 at 5:30 AM
Edited Jan 30, 2008 at 5:30 AM


LordIkon wrote:


shawmishrak wrote:
  • Garbage, garbage, garbage! We're getting 3 GCs per second, running 40-70 ms out of every second.


What is producing the garbage?


From what I can tell, it's almost exclusively being generated by JigLibX. Of course, this is for a Windows profile so there could be some engine code that allocates on Xbox and not on Windows. It's improbably, but possible.

If we're serious about keeping JigLibX support, I'll need to work with the JigLibX developers or just maintain a custom build for our own purposes to try to reduce this.



I believe putting the terrain into the content pipeline can be put into a task for 0.20. If this is the case I believe that the camera changes and terrain changes planned will take me 2-3 months alone. Especially if we truly want to support terrains that are not "square", because I've never done anything like it, it may be a simple change, it may require rewriting huge portions.


I wouldn't worry too much about the non-square terrain right now. We can easily live with it. I would concentrate on getting square terrains working optimally and loading them through the content pipeline. We can discuss this in another thread, when you're ready to start serious work on it.


The vertices themselves should be setup in an (n + 1). "Should" be is the key phrase there, because I just realized that somehow I went back to a (n) setup over the last 6 months. It must be when I went to the terrain patch setup. I used to use a n + 1 setup, so a 4x4 image would give you 25 vertices, 5x5, which when connected ends up looking like 4 quads. If you'd like to have n + 1 x n + 1 geometry I might be able to give you the heights at each corner of a pixel in the bitmap itself. However, the corner of each pixel would need to be an average of the pixels around it which would cause the borders to look odd. Finally, we could change the entire terrain system to require bitmaps of power-of-two + 1 width and height. I'm pretty tired so maybe I am forgetting a better way.


I honestly don't care how the vertices are set up. What matters to me is getting at the same vertex data that is being used to render the terrain. Whether that's 2^n x 2^n or (2^n + 1) x (2^n + 1) I couldn't care less. I can get at the raw vertex data now, but I need a way to convert it into a 2d array of heights. Basically, I need the following:

  • float[,]: indexed by integer x,z from (0,0), where each unit in x/y direction is the same as the distance between vertices in the terrain geometry.
  • terrain scale: The planar distance between vertices.

So, the z distance between float[2,3] and float[2,4] is terrain scale.

Does that make sense? It's late and I'm tired so I may not be making the most sense.
Coordinator
Jan 30, 2008 at 6:07 AM
Edited Jan 30, 2008 at 6:08 AM
Maybe I'm confused, doesn't the heightdata array, which is a float, array, hold the heights of all the vertices? The Heightdata holds the information, scaled on the Y by the terrain scale. The X, Z coordinates remain unscaled.

So the point (5 (x), 5 (y), 5(z)) would be accessed in the array by using 5 (x), 5 (z), and you would get 5 (the y-value) returned. If the terrain scale were 4 you would get a 20 returned for a y-value, but would still use 5, 5 in the array.

The way you describe the problem sounds like the way that heightdata is setup. In fact, the boxes are acting exactly how I would expect them to act, they're falling through terrain in certain parts because the terrain is at LOD.Med, which means 1/2 the vertices along X, and Z. (1/4 the total verts). I'm not sure reorganizing heightdata, would be a good idea once we have dynamic LODs in the terrain. Each chunk of terrain may need its own physics data that can change on the fly.

Oh, and if some of that didn't make sense, it is because I'm tired as well.
Jan 30, 2008 at 3:16 PM
Correct me if I'm wrong here. Let's say the input terrain map is 4x4. Then heightData will be a 4x4 array of height values. The generated geometry, however, will be 5x5. Right?

Switching to High LOD does not fix the problem.
Coordinator
Jan 30, 2008 at 3:50 PM
Edited Jan 30, 2008 at 3:50 PM
A 4x4 image will produce 9 quads in a 3x3 layout. Each pixel of the image corresponds to a vertex in the heightmap.

For example, if our image is 4x4:

x - x - x - x
|   |   |   |
x - x - x - x
|   |   |   |
x - x - x - x
|   |   |   |
x - x - x - x

Notice we have 9 quads, and each X represents a pixel in our image.
Jan 30, 2008 at 3:52 PM
Hrm, alright. Maybe it's expected to be quad centers then. I'll have to play around with it.
Jan 30, 2008 at 5:24 PM
As you know I am still getting into this and so do not know quite what to say here. I do agree though with LordIkon about releasing 0.19 but not putting it as the default newest release.

I am going to try and do some HUD stuff for the engine, after what you guys said and following the code guidelines. For now I am reading through the latest code since it is completely different to what I was looking at before in the 182b release. I will let you know of any advancements with the progress of the HUD stuff :D

Keep it up guys! :D
Coordinator
Jan 30, 2008 at 5:54 PM
Yes, v0.19 was literally created from scratch. The only things that remain from 0.182b are parts of the terrain and camera systems.
Coordinator
Jan 30, 2008 at 9:16 PM
Stealth, I'll be interested to see what you come up with for the new engine, unfortunately the patch you made for the last one might not make it because we're not making any changes to the old version except bug fixes.
Jan 31, 2008 at 5:24 AM

shawmishrak wrote:
Sturm, I just uploaded a patch with a custom Activator.CreateInstance replacement for BaseManagers. There's a new QSActivator static class that allows instantiation of any type, assuming a constructor that takes a QSGame parameter. I don't know why I didn't think about using Reflection earlier.


I would rename the CreateBaseManager to CreateInstance, as it's used to create other items than BaseManager (such as handlers) otherwise looks fine. Should I do the rename and check it in?
Jan 31, 2008 at 8:45 AM
Thanks lordIkon, Its okay if the patch I uploaded gets thrown away since I am learning this new code and attempting to write some HUD stuff for the new system.
I am still, well lets say confused with a few things, but am slowly catching up with the new code.

I am writing down ideas on paper for me to try and implement for the system; HUD stuff that is.

Can I suggest that since you have a window manager and controls etc that you guys were to write controls such as text boxes and dropdown boxes (skinable would be kwl). Reason I say this is lot of people want this kind of stuff but fine it hard to find or implement themselves; Just a thought.
Jan 31, 2008 at 11:44 AM
We are either going to use http://www.codeplex.com/neoforce or create a similar system (though not commiting to anything here). But if you have any special requirements go ahead and create issues for them (Set status as proposed) and we will consider them.
Jan 31, 2008 at 1:12 PM
Im not sure relying on another project is a good idea if it can be done in-house. JUst my feeling, dont hae any real justifications :)

Its only minor, but netork support for xbox is simple enough once Ive sorted out how it all connects to the engine as a whole. Also, we seem to have a lot of patches floating round. Are they all for 0.19?
Jan 31, 2008 at 1:52 PM

Im not sure relying on another project is a good idea if it can be done in-house. JUst my feeling, dont hae any real justifications :)


At some point we need to take advantage of third-party libraries. Doing everything in-house is a sure-fire way to never finish the product. I would love to do an in-house physics solution, but I also realize the time just isn't there. Wrapping PhysX and JigLibX gives us great physics and frees up my time to tackle other issues.


I would rename the CreateBaseManager to CreateInstance, as it's used to create other items than BaseManager (such as handlers) otherwise looks fine. Should I do the rename and check it in?


Might as well. No reason to push it off. Does that complete 0.19?


Also, we seem to have a lot of patches floating round. Are they all for 0.19?


There should only be one patch, and that's my Activator.CreateInstance replacement.
Jan 31, 2008 at 3:06 PM
We are very close. I will include your rework in my next patch, which also fixes my last issue. The patch also contains the removal of the prototype code and all related resources.

Should we remove the 0.182b code as well or do you want to keep it for reference?
Coordinator
Jan 31, 2008 at 3:19 PM
There's no need to keep 0.182b in there, it is just confusing, especially since we don't need it to be under source/versioning control. It will still be able for download in the release section anyway, for awhile at least.
Jan 31, 2008 at 3:48 PM
Ok, I'll remove all non 0.19 assets as well.
Jan 31, 2008 at 4:12 PM
Just to bring closure to this: your patch (Sturm's) is the last that will be applied for 0.19, correct?
Jan 31, 2008 at 7:38 PM
Yes and it will also remove any assets which are not related to the 0.19 release, so that noone gets confused about what's in the source tree.
Jan 31, 2008 at 8:48 PM
It'll probably cut the source tree size by half as well.

Sturm, out of curiosity, are there any legal issues with distributing all of the programs that we do in the source tree? Like windiff. I'm just curious, as a lot of EULAs like to frown upon distributing raw binaries.
Feb 1, 2008 at 7:53 AM
You are right I will remove diffmerge as it does exactly that, I'm not sure about windiff though. I'll investigate that.
Coordinator
Feb 1, 2008 at 2:23 PM
If they're still freeware you could include some links on where to download them, put them in a .txt file.
Feb 1, 2008 at 7:12 PM
I will add it to the readme, and include it in the BE start up checks.
Feb 2, 2008 at 4:24 PM
Well, JigLibX Physics Implementation now? I agree that we need it for Xbox, but I also think that we could delay this a little and choose to implement a important feature that the engine still doesn't have yet, for example an animation system. The engine already have a physics system implemented. Also, an animation system is one of the most important feature an engine have.
Feb 2, 2008 at 6:33 PM
I tend to disagree, granted that animation is important and gives a game a much better feel, the actual impact on the engine is rather small compared to the physics implementation. The physics system impacts most other systems and any issues in that system can affect all others. So from a engine perspective the physics system takes precedence over the animation system. We currently haven't set any plans for animation, so you can create an issue for this.
Feb 2, 2008 at 6:54 PM
The other issue is generic vs. specific requirements. A physics implementation is generic. You represent collidable bodies, assign properties to them, and simulate them. There's really no variance from game to game here. An animation system on the other hand is more game-specific. Every game has differing requirement on what they need from the animation system. Some games, like racing games and puzzle games, may not have any predefined animation at all. They may be completely procedural. Other games may require full skeletal rigs integrated with a ragdoll simulation. Still others fall in-between these two extremes. The trick for us is to abstract this enough to accomodate as many as we can.

By all means I would love to get a full animation system going. But at this point, I'm the only one handling everything related to graphics and physics, and my time is limited. So I need to prioritize, and maintaining the Xbox builds is one of these priorities. Like I said in the past, we're not supporting Xbox builds, but we will be providing them. When Xbox development becomes feasible, then we can start supporting them, assuming Microsoft's solution to Xbox distribution isn't compeletely assnine like I have a feeling it might be.

If someone wants to volunteer for preliminary animation work, then by all means let me know!
Feb 5, 2008 at 7:55 AM
Edited Feb 5, 2008 at 8:05 AM


shawmishrak wrote:
...
If someone wants to volunteer for preliminary animation work, then by all means let me know!


Well, if someone wants a reference for a animation library, here it is: http://www.codeplex.com/animationcomponents. But it is using XNA 1 yet.
Here is the convertion for XNA 2: animation library XNA 2
You can also try a project where you can move and control an animated dwarf model CONVERTED TO XNA 2, here: Animated model project
Coordinator
Feb 5, 2008 at 2:49 PM
I don't believe that library is compatible with .FBX files either. That would need to be looked into.
Feb 5, 2008 at 3:23 PM


LordIkon wrote:
I don't believe that library is compatible with .FBX files either. That would need to be looked into.


Yes, it does work with FBX.
Coordinator
Feb 5, 2008 at 3:44 PM
Cool, it has changed since the last time I looked at it. Does it include skinned animation as well like the sample on the XNA site?
Feb 7, 2008 at 2:25 AM
Hi,

What you think about use fbx how basic scene format? We can modify our content importer to allow more the one Model from the fbx file. I think that would be a good start.

Feb 7, 2008 at 2:41 AM
Use FBX as the format for the entire scene? I think that would be too restricting. We need to handle image-generated height maps and entity positioning, among many other things.
Coordinator
Feb 8, 2008 at 5:01 AM
Looking through the model processor, I see we can probably remove the 'swap coordinate system' stuff.
Coordinator
Feb 8, 2008 at 5:23 AM
Am I able to store multiple index buffers in a content file?
Coordinator
Feb 8, 2008 at 6:06 AM
Currently the terrain itself is simply positions and normals, nothing else. However the shaders need terrain maps which give the locations for different texture types for texture splatting. If I processed these into a content file, how would I pass the texture to the shader? I guess they're already processed into content files, but during runtime which we're looking to avoid.
Feb 8, 2008 at 4:07 PM
Yeah, the "swap coordinate system" code can go.

Use external references. Look at how the material processor stores effect references. You can do the same for textures. At run-time, you can load Texture2D's directly from your terrain content file.

You can store whatever you want in a content file. 100+ index buffers and 1000+ vertex buffers are possible, there's no limit.

You might want to split the processing into two content processors. Have one parse an XML description of the height field, and another parse the height image. Then, you just add the XML file to the content project, and the processor will automatically link to the textures and shaders, then call the height field processor on the height image, and store an external reference to it. At run-time, you just load the output from the XML processor, which in turn links to the height field data content file.

I think most of what you need is contained in the model and material processors. They should show you an example of how to create and store vertex/index buffers, as well as external references to effects and textures.
Coordinator
Feb 8, 2008 at 6:01 PM
I've never created or parsed XML, so I'll need to start with learning that. Could the heightfield simply load into a single vertex buffer like is currently does, and then each patch create index buffers?

Current rendering logic loops through quad-tree sections and gets the index buffers from the patches within them. How will I recreate the quad-tree objects recursively at runtime from a content file I wonder? phew, this is becoming more difficult the more I think about it.
Feb 8, 2008 at 6:59 PM
using xml is very simple, and if you made your objects serializable it's a bliss using .net simply use XmlSerializer and merge the nodes together and you are done building, and when building your objects deserialize them and everything is good :)
Coordinator
Feb 8, 2008 at 7:58 PM
That part I believe will be the easy part, I'm just wondering how I'll open up a content file, create a quad-tree, create four children, create four children on each of those children, etc....and go through that process in a content file. Technically the data will be already created I guess, I'll just need to know when to create children and then feed the info into them.

I may end up creating a very simple program (camera and terrain), and then making a content reader/writer for a non-quadtree terrain to start with, just for practice. I see how Shaw does it in his, but going through terrain seems to be slightly different than just cycling through meshes.
Feb 8, 2008 at 11:59 PM
If you implemented IXmlSerializable you do not have to worry about creating any children. as this would be done when a node deseriliazes, it would simply create any childnodes. So you only need to do your stuff in the read and write methods.
Coordinator
Feb 9, 2008 at 2:22 AM
That sounds pretty damn useful. Can it make children within children?
Feb 9, 2008 at 8:43 PM
Well the serializer doesn't do the job for you (unless the basics) I made a very simple example of a custom serializer, of cause this is not really a relevant example as you could simply serialize it directly. But imagine yuo would have a Dictionary then you would have to do some custom serialization.

    public class Node : IXmlSerializable
    {
        public Node()
        {
            this.Children = new List<Node>();
        }
 
        public Node(Node parent)
            : this()
        {
            this.Parent = parent;
        }
 
        public List<Node> Children { get; private set; }
        public Node Parent { get; set; }
        public string Name { get; set; }
 
        System.Xml.Schema.XmlSchema IXmlSerializable.GetSchema()
        {
            return null;
        }
 
        void IXmlSerializable.ReadXml(System.Xml.XmlReader reader)
        {
            reader.ReadStartElement();
            this.Name = reader.ReadElementContentAsString();
            XmlSerializer serializer = new XmlSerializer(this.GetType());
 
            reader.ReadStartElement();
            int count = reader.ReadElementContentAsInt();
            int index = 0;
            while (index++ < count)
            {
                Node child = serializer.Deserialize(reader) as Node;
                this.Children.Add(child);
            }
            reader.ReadEndElement();
 
            reader.ReadEndElement();
        }
 
        void IXmlSerializable.WriteXml(System.Xml.XmlWriter writer)
        {
            writer.WriteElementString("Name", this.Name);
            writer.WriteStartElement("Children");
            writer.WriteStartElement("Count");
            writer.WriteValue(this.Children.Count);
            writer.WriteEndElement();
            foreach (Node child in this.Children)
            {
                writer.WriteStartElement("Node");
                (child as IXmlSerializable).WriteXml(writer);
                writer.WriteEndElement();
            }
            writer.WriteEndElement();
        }
    }
 
    class Program
    {
        static void Main(string[] args)
        {
            Node root = new Node();
            root.Name = "Root";
            Node child = new Node(root);
            child.Name = "Child" + child.Parent.Children.Count.ToString();
            root.Children.Add(child);
            child = new Node(root);
            child.Name = "Child" + child.Parent.Children.Count.ToString();
            root.Children.Add(child);
            child = new Node(root);
            child.Name = "Child" + child.Parent.Children.Count.ToString();
            root.Children.Add(child);
 
            XmlSerializer serializer = new XmlSerializer(typeof(Node));
            StreamWriter sw = new StreamWriter("dump.xml");
            serializer.Serialize(sw, root);
            sw.Close();
 
            root = serializer.Deserialize(File.OpenRead("dump.xml")) as Node;
        }
    } 

sorry if it seems a bit off, I used C#3.0
Feb 9, 2008 at 11:22 PM
Hi,

Take a look this. it´s very fast, easy to you and work with Compact framework http://www.codeproject.com/KB/dotnet/FastSerializer.aspx.
Feb 10, 2008 at 4:01 AM
Unfortunately it uses ISerializable which isn't supported on Xna (And hence xbox)
Coordinator
Feb 14, 2008 at 5:00 AM
I'm almost starting to regret being the one responsible for the terrain component. At one point terrains were one of my favorite aspects of game programming, and a great learning experience, but my real area of focus (over the last couple of years at school, and more recently work) has been gameplay systems, like input, cameras, AI, NPC interaction, U.I., etc.... Terrain optimization and packaging the information into content files and creating and reading from XML is far from what interests me. It makes taking the time to create systems like content processors for terrain very tedious, aside from the fact I've never worked with content processors or XML, so I predict a good amount of time on that before any progress is made on the terrain side of things.

Any advice on this one guys? I just feel like if I was on something I was more familiar with, experienced with, and interested in, I'd be getting a WHOLE lot more done, and be more more enthusiatic to sit down and code this stuff each night.
Feb 14, 2008 at 5:57 AM
Don't feel bad about not working on the code every night. It's actually been awhile since I've had time to touch the code. The last few days for me have been spent working on a LISP interpreter.

If someone else wants to take over the terrain loading/processing, that's fine. We're still at the initial coding stages, so it's hard to specialize.
Coordinator
Feb 14, 2008 at 6:31 AM
I know it is important that we get it into a processor so we can cutdown on loading times, which will be important for streaming terrains when changing scenes. I just don't feel productive right now. I certainly have much more motivation to do other things like cleanup the camera system, or create an input polling system. I just don't think the terrain processor can be put off either.
Feb 14, 2008 at 10:58 AM

LordIkon wrote:
I know it is important that we get it into a processor so we can cutdown on loading times, which will be important for streaming terrains when changing scenes.


Since we aren't going to support streaming terrains for a long time, there is no reason to implement a processor for this now. We are able to load a terrain and display it for the moment lets stick to that.


LordIkon wrote:
I just don't feel productive right now.


If you are writing code or designing it in your head, you are being productive. Just keep the momemtum and sooner or later everything starts rolling again.


LordIkon wrote:
I certainly have much more motivation to do other things like cleanup the camera system, or create an input polling system.


Then go ahead and rework the camera system, it's just as important as the terrain, and both are target for 0.20 anyway.


LordIkon wrote:
I just don't think the terrain processor can be put off either.


Sure it can. It might incur more work for other systems, like physics, but a later rework would mostly require code to be removed, not really any rework, unless I misunderstand the issues.