Engine changes on the way

Just a minor update this time. I haven’t done much more with the terrain or rendering code, but here’s what I am planning next for the engine.

In addition to terrain and culling, I’m doing a bunch of work on the internals itself, to make the code simpler and more readable. Gone will be the DragCamera and FreeCamera classes, which were really not much more than wrappers with XNA input functionality shoehorned in. From now on, input will be decided by the user, as I felt that it shouldn’t be the responsibility of the rendering engine to decide what control what.

Additionally, debug features will be in their own class, with the input also separated. This will probably lead to the development of a Immediate Mode GUI which would be just enough to do some of the more common actions for scene editing. I don’t really want to make a full-fledged GUI library because there are too many of those, and it’s easier to code in GUI elements by methods instead of using several objects and events.

Back on the rendering side of things- some more cleanup on shader code, and figure out a way to finally add full specular mapping support without bloating the buffer too much. But if that fails, I’ll bite the bullet and use an additional buffer for specular data. Also, a forward renderer! It seems like everyone and their grandma is too focused on deferred lighting these days, but left the simple yet overlooked forward rendering in the dust. Deferred rendering and lighting is not always the silver bullet for graphics… it has relatively more upfront cost and not worth it for basic outdoor lighting situations. They should be friends with forward rendering, which is still faster for many setups.

More user-friendliness

I don’t want users to dig too deep into the codebase to make the configurations they want to see take place in their game. For instance, right now the only way to change the Gaussian blur factor is to go into the effect class that uses the blur you want to change, and edit the parameter value from there. I want shader parameters to be editable on the high level, but without exposing the functions of the class that uses it. If possible, they should be able to use the engine as a library, and still tweak all the settings for the built-in effects.

This leads to more accessible methods to edit or create scenes, as well. Along with GUI interaction mentioned above, the changes you make should be persistent. Yep, that means loading and saving files for scenes. This feature will come eventually, but I already think JSON would be a good format to represent the data. It’s expressed in a concise manner, and there are many serializers/parsers for JSON out there, which is why I prefer using it.

With these changes, I can hopefully get closer to releasing an official candidate for people to download.

Advertisements

6 thoughts on “Engine changes on the way

  1. Nice plans there! I am looking forward to seeing shadows in the forward renderer :P! I am wary of shadow mapping after the countless hours of trying to make them work, and I’m not sure I am ready to even think about shadowing again, but if you get it done I’ll give it a go.

    I also have opensourcing plans and I’ll look over your code to see if I can maintain a very basic level of compatibility, but it might not be possible because I’ve been moving away from the content pipeline for quite a while now. Only shaders and a handful of resources are loaded from the pipeline, the rest is traditional binary loading from disk. Mesh loading is at least for me ridiculously slow at loading from the pipeline. This move might turn out to be favorable after all, since it might make the move over to SlimDX or something else easier, since XNA is cancelled.

    • Suprisingly, loading content hasn’t been slow for me. The slowest part for me was when I created 10’s of thousands of instances, adding them incrementally to a list for some reason takes a few seconds. I owe it to the uncompressed .xnb format, it must be very fast but larger in size. I do all my builds as Debug projects so I haven’t really tested loading times of compressed content.

      • For me loading though the pipeline is about 100 times slower than from my format. Keep in mind that for about 10-20 models, even with this 100 times factor, loading though pipeline only takes 2-3 seconds. You might be fine with that. I prefer 30 ms :). Actually, I prefer my engine to start instantly. Even on a 64 square kilometer map, with 269000 boulders with physics, the engine starts up in a couple of seconds. It is not done loading and will continue to stream the content in, but it is interactable.

        Have you tested shadow mapping thoroughly? My implementation had three issues:
        1. Shadow flicker. I managed to fix it, but only for coordinates around zero. Around 1000 there is minor flickering that you barely notice, around 2000 there is more, and above 4000 there is noticeable flicker. And it goes up, until the point where my flicker compensation though texel snapping does nothing.
        2. On some angles, in the corner, the overlayed frustums would not line up correctly, giving a small but nasty visual artifact.
        3. Making the shadows have a finite radius was problematic. You could see strange artifacts when items at the border of the most distant frustum would fail to render correctly, even causing the entire scene to render in shadow. I compensated for this by rendering less than the radius to the shadow map, so if I had a radius of 1000, I only rendered objects that were let’s say 800 units or closer to the camera. Having a shadow range equal to the far plane makes shadows ugly because there are not enough splits to handle the range.

        And besides this, the shadows were kind of ugly when you stopped to take a look at them. I compensated for this by making the shadow color lighter. But still in the end, a colossal failure.

        Do you have any of these issues?

  2. I can say that I’ve noted some issues with problem #1 in my engine. Exactly as you said, once the camera is about 1000 – 1500 out from the origin I get flickering, as opposed to the quite stable shadows nearer the origin (and this is despite texel snapping as well). I’m not sure what it is, probably some sort of floating point limitation… but I really haven’t dug into it yet.

    • DwarvesH and drheinous, from what I’ve read in a GameDev topic this seems to be a rounding error that builds up in larger values. But for that topic the problems only started occurring when the distance was greater than 5000 or so. In that guy’s topic, some of the vertices in object closeups even started jumping a bit. The way to do a very large world seems to be shifting your camera and objects back closer to the origin, kind of like wrapping the world back to zero. But I do not know how this can be cleanly done with objects controlled by physics.

      I give little regards to the faraway shadow splits, because in my game you won’t see them as much- not like it’s gonna be a flight simulator or anything. Which is why I have my split scheme set very close for the first 2 splits. The farthest 2 splits will only be updated once every X frames after optimizing.

      • Well my 64 square kilometers (if 1 heightmap unit is 1 meter) should be the prefect test for that. I outlined an algorithm that should work fine with physics, the only question is if the shadows will do a small jump when you otherwise seamlessly jump back the world to zero every N units.

        I’m checking out you shadow code these days.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s