Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 20 Feb 2007
Offline Last Active Jul 31 2014 08:28 PM

Topics I've Started

[DX10] Effect organization question

16 December 2008 - 10:10 AM

So this is sort of a broad question and topic, but in my eternal state of "lets play with this new shiny thing!", I want to put together a DX10 engine that I can play with some advanced techniques in. From a scene management point of view, I'll probably go with your standard scene graph and call it a day, but what I am interested in is how you guys handle the fully programmable pipeline. Obviously it will be handled through .FX files, but do you tend to have one gigantic monolithic .FX for drawing 90% of what's in your engine, or do you create individual .FX files for every possible object? The latter method seems very cumbersome. Coming from an OGRE background, I am used to a pretty robust material management system, but I am not sure if DX10 effects can be used in the same way. Is it possible to create, lets say, a VP/FP combo that can cover 90% of the engine (as most objects are drawn pretty much the same way) and just reference those programs in the various .FX files? Is this how most people do it? Obviously every object in the scene should be able to dictate what effect it's drawn with, but I am more curious about the organization of the effects themselves. There isn't exactly an overgrowth of DX10 code out there, and what you do find tends to be very test bed code and doesn't contain what many would consider "proper" structure.

Texture shadows and directional lights

08 August 2008 - 04:20 AM

We currently have VSM (variance shadow maps) working great in our game engine, but given the way our world is setup, VSM's only work "out of the box" for indoor scenes. We use mostly directional light (the sun/moon) in outdoor scenes, something VSM is not setup to handle very well. I've read that you can tweak the calculations slightly, to do an orthographic projection in the case of a directional light, but after much fiddling, I haven't gotten it to work. So my question is, what texture shadow techniques do you guys use for directional lights? Have you been able to tweak VSM with the required orthographic projection for directional lights? Have you tried something like Layered VSM, or cascaded shadow maps using VSM as one of the shadow drawing techniques? I guess I'm just looking to get an idea how people are doing outdoor scene shadows with directional lights. I prefer a texture based method like VSM so that we can blur/filter the shadow map (soft shadows).

Data storage for a MUD

09 July 2008 - 10:44 AM

I've been working on my own next generation MUD server for years, but I've finally gotten down to brass tacks and want to complete it. The issue I am running in to now is data storage. I am definitely going to use an RDBMS back end, but how do you make it extensible? I can release the MUD server with a sane default data storage setup, but what if the new MUD administrator wants to add new properties to his Player object? I don't want them to have to update the database tables to reflect this. So I came up with the idea of making the data store a bit more property driven. For instance, rather than storing Player to a Player table, I store it to a Thing table, which has a bunch of foreign key references to a ThingProperty table, which stores free form properties for the object. Two issues I worry about with this: What is the definer of the object "base class", so to speak? Do I simply use reflection to basically serialize the object to the data store? Do I use .NET attributes to determine what properties of an object are actually persisted? Do I store something like a "ThingClass" in the database, that determines exactly what properties of every object type should be saved? Currently I am going down path C, defining every object "class" in the database, using a tool I call my MUD Schema Editor. Part of that editor is the ability to create the partial C# class stubs for those object types (honoring the hierarchy the MUD administrator decides on). Does this make sense? Is it over engineering? Is performance going to be an issue? Obviously the ThingProperties table could get huge, as it will contain a row, for every property, of every object, in the MUD world. Also, there has to be a differentiation between a blueprint of an object and the instances that have been created of the object. The instances need to also be persist-able, raising the number of rows that table could have even higher. In the "old world" of MUD servers, you really had two ways to define things: The DIKU way, which were this space delimited text files, that changing the format or storing a new property was very painful. And the LPC way, where every entity in the MUD world was a complete code object that was loaded at runtime (and probably sub classed from a system object, like /Sys/Lib/Mobile). Some projects like ColdC have come along, and what I am trying to achieve is sort of a hybrid. I want my data definition separate from code (so not LPC style), but I want my data store to be flexible to the world the MUD builder wants to make (not DIKU style), without a ton of code changes. I guess I'm not really asking a question, so much as looking for validation of my ideas (or invalidation of them, which serves my purposes just as well at this point).

Rendering planets (from space only)

10 February 2008 - 04:05 PM

Assuming I've created a tool to quickly generate planet textures for me (using libnoise's complex planet example), what is the most efficient way to render said planet from space? I will never need to get very low in to the orbit, so I think Sean O'neil's algorithms for rendering zoomable planets is a bit heavy weight for what I need. I've heard people say you should use cubes to render the planet, but I can't really wrap my mind around the theory. I will eventually add effects like atmospheric scattering, but I just want to get a nice looking, circular planet rendered first.

Fast UID algorithm in C++

25 January 2008 - 03:38 PM

Does anyone happen to have a fast algorithm to generate a unique ID in C++? I would prefer something that could squeeze inside a long. The UID's don't have to be globally unique, just unique to the current install of my game. I figured I would want to use the current date in some way to derive a UID, I just wasn't really sure what to do beyond that.