High Poly?

[banksy]

So how does this engine handle high poly. Because I may plan on making a map using 3ds Max or Maya which will be high poly. I also plan on using high poly models in my current project. The Frozen Sand team (urban terror) are working on a new engine which will work great with high poly, and are also working on lighting which is a key feature in creating a realistic atmosphere. So where is unvanquished at in all this? What can it and can't it handle?

[velociostrich]

So how does this engine handle high poly. Because I may plan on making a map using 3ds Max or Maya which will be high poly. I also plan on using high poly models in my current project. The Frozen Sand team (urban terror) are working on a new engine which will work great with high poly, and are also working on lighting which is a key feature in creating a realistic atmosphere. So where is unvanquished at in all this? What can it and can't it handle?

Please define what you mean by high poly. Do you mean having a high polygon count or do you mean high polygon modeling (where you would be baking normals from your high poly to a low poly model)? As for the latter, that works just fine. As for the former, you're not going to find any realtime 3d game engine that will handle "high" poly (i.e., in the millions) counts on static or dynamic meshes. GPUs just do not (yet) have enough power for that sort of thing. (At least, not enough power for displaying more than one high poly model at a time.)

[banksy]

High polygon models. Due to the fact that I plan on creating the map in Maya and important it into radiant as a model because radiant limits what you can do with a brush meaning less detail.

[Fuma]

GL3 can work well with "high" ( within reason ) poly modeling because it keeps almost all geometry in static VBOs and draws each non-glow mapped surface(s) in a single pass.

GL3 supports realtime lighting and shadowing, but no one is using it in maps yet because it is a lot more expensive than lightmaps.

If you look at modern games, they typically keep real time shadowing to a maximum of 1 or 2 lights per scene because of how expensive it is.
Some games forgo realtime lighting and shadowing altogether and use lightmaps pretty much exclusively ( see: RAGE ).

Another issue is the mapping tools we use (GTKRadient, NetRadient) don't really support the lighting capabilities of GL3.

[banksy]

Mm I see. Well gtkradiant is back under development again so hopefully a lot of issues faced in 1.5 will be resolved including lighting and grid positioning, as well as many others

[poVoq]

Try DarkRadiant: http://darkradiant.sourceforge.net/ (which should probably get an Unvanqished plugin sooner or later I hope)

[banksy]

I'm running osx so I can't :/

[velociostrich]

High polygon models. Due to the fact that I plan on creating the map in Maya and important it into radiant as a model because radiant limits what you can do with a brush meaning less detail.

I am not familiar with the process to do this in Maya, but to do this in Blender, you have to model in much the same way as you do in Radiant. The biggest issue is that Radiant quantizes geometry: i.e., it snaps coordinates to grid squares. (I'd guess it does this to minimize file size.) There is a tutorial series on katsbits aimed at Blender that you may find useful, if you're not already aware.

What you will probably have to do is take the giant map model that you create in Maya and slice and dice it into many separate models so that the renderer can cull those individual chunks. Once you've placed those in Radiant, you'll probably also have to fill in the empty space around the models with brush geometry so that the compiler can calculate PVS.

Also, I don't know what the engine's behavior is for handling collisions with map models, but I imagine that it takes a very course approach and uses AABBs for them. What this means is that any time you have empty space in your model that is appreciably large (such that the player could fit into it), you will probably have to break that mesh into smaller chunks again.

Some games forgo realtime lighting and shadowing altogether and use lightmaps pretty much exclusively ( see: RAGE ).

I had no idea Rage doesn't have realtime shadowing! Surely it has at least realtime phong shading, right? I mean, how else are normal maps and the like going to work? Also, I thought that they had promised some time after Doom 3 to implement soft shadows (what I think is called the penumbra of a shadow?)

Try DarkRadiant: http://darkradiant.sourceforge.net/ (which should probably get an Unvanqished plugin sooner or later I hope)

I'm running osx so I can't :/

You probably could compile DarkRadiant on Mac OS X but with Gtk+ as a dep, I'm sure it'd be a real PITA. MacPorts or Fink might make it easier, but they can both eat up an awful lot of HD space (i.e., many gigs).

[banksy]

Porting it from Maya wouldn't be the only long task. I now realize that I would have to clip the entire map again as models don't have a clip when imported.

I am awful at porting programs to osx, and assume if it wasn't that hard a task, it would have already been done considering darkradiant has existed for quite some time now.

[Fuma]

I had no idea Rage doesn't have realtime shadowing! Surely it has at least realtime phong shading, right? I mean, how else are normal maps and the like going to work? Also, I thought that they had promised some time after Doom 3 to implement soft shadows (what I think is called the penumbra of a shadow?)

Rage DOES render shadows for moving objects ( the player, enemies, etc ), but these are simply modulated against the existing statically lit geometry.
This is much cheaper to render than a fully realtime system, but it causes double shadowing where you can see the realtime shadow on top of the already shadowed geometry. The realtime shadow's direction is probably determined by either a light grid type system like we have, or a single specified direction for the entire level ( the direction of the sun ).

Of course it has phong, blinn-phong or another type of shading. A realtime lighting/shadowing system is not a prerequisite for this.
Normal maps can also work fine without a realtime lighting/shadowing system.

Doom 3 did not have soft shadows because it used a stencil shadow system instead of shadowmaps.

I would assume that the IDTech5 engine supports realtime lighting and shadowing just fine, but they chose not to use it for RAGE for one reason or another.

One reason not to use it in RAGE would be to achieve radiosity without a terribly expensive runtime cost.

Additionally, the game RAGE itself was mostly concerned with showing off IDTech5's Megatexture technology which allows for completely unique textures on every surface.
In this case, using precomputed lighting makes sense since it meshes well with the tech.