Jump to content

Elite Force Engine Feature List


  • You cannot reply to this topic

132 replies to this topic

#21 Scooter

Scooter

    The Canon Man

  • UberGames Admin
  • 2,545 posts

Posted 10 March 2006 - 06:23 PM

MD4 model format:
http://gongo.quakedev.com/md4.html

#22 TiM

TiM

    Administrator

  • UberGames Admin
  • 3,425 posts

Posted 11 March 2006 - 04:38 AM

Yeah, I've read that article, and I've looked over the MD4 code in the Q3 engine source, altho it didn't make too much sense to me lol. :)

In any case, I think I read somewhere that Raven's MDR format is mainly their own extension of the Q3 MD4 format.

I think the main difference between the two is that Raven made a new compile method for theirs, and the model format consolidates all of the LoDs into the one file (as opposed to *.md3, *_1.md3 and *_2.md3 in vanilla Q3 ).

In any case, bone deformation kicks the stuffing out of vertex animation, so I would hope that being able to keep/create a modifiable bone animation model system would be possible. :)

-TiM

#23 TiM

TiM

    Administrator

  • UberGames Admin
  • 3,425 posts

Posted 12 November 2006 - 07:39 AM

Hrmm... I wonder if it would be possible to make our own model format, based off of MD4... There are a few things I'd like to add to that format:

-Consolidate LODs into one file
-Separate the animation data, so it can be applied to multiple models.
-Consolidate the models from the Quake III head, torso, legs setup into one main full model, and then use the bone system to dynamically deform them as needed (This is essentially what they did in JK2, JKA, SoF2, Doom 3 and HL2, but wasn't originally done in Q3 as it was too processor intensive at the time)

Either way... I'm going to need to go away and become l33t in Quaternion mathematics before I can attempt this... :)

*********************************

Anyway, another feature I've been thinking of:

Improved support for static meshes.

Just going around HL2, Doom 3 and UT2K4, I can see that the overall complexity of the maps aren't overly superior to those of Quake III.

The main difference is that in these newer games, they make much more use of making ingame map objects as models, instead of building them out of brushes. This usually means that the elements are usually a lot more detailed, with more precise shapes.
And in most of the cases, especially in UT2K4, the models have the lighting detail painted into the texture, which gives a far superior shading detail than having the computer calculate all of the lightmapping on it.

The problem is that map objects aren't really well handled in the Quake III engine. You can either have them as misc_model_breakables... in which they are spawned as separate entities on the client when the map is loaded, or you can make misc_models and have them built straight into the BSP tree when you compile the map...

In the first instance, absolutely no collision is allowed unless the model is encompassed in clip brushes by the mapper. In the second, collision is allowed... although it's plastered with warnings saying not to use overly complex models, otherwise the collision code can cause some pretty hefty system lag.

So I think it's worth seeing if it's possible to build a more efficient system for collision detection on models.

-TiM

#24 Scooter

Scooter

    The Canon Man

  • UberGames Admin
  • 2,545 posts

Posted 14 November 2006 - 12:02 AM

A bone system would be awesome.

http://en.wikipedia....wiki/Quaternion

Just going around HL2, Doom 3 and UT2K4, I can see that the overall complexity of the maps aren't overly superior to those of Quake III.

The main difference is that in these newer games, they make much more use of making ingame map objects as models, instead of building them out of brushes. This usually means that the elements are usually a lot more detailed, with more precise shapes.


Another thing I've noticed is that they use more detailed textures.

So I think it's worth seeing if it's possible to build a more efficient system for collision detection on models.


I agree wholeheartedly, and while we're at it, how about ditching bounding boxes in favor of something more precise?

http://en.wikipedia....ision_detection
http://en.wikipedia....Bounding_volume

And while I'm dreaming: http://en.wikipedia....ki/Game_physics
I don't suppose anybody is already working on adding a particle system or ragdoll physics to Quake 3?

#25 TiM

TiM

    Administrator

  • UberGames Admin
  • 3,425 posts

Posted 14 November 2006 - 07:05 AM

A bone system would be awesome.

http://en.wikipedia....wiki/Quaternion


Hahah yeah....
We did Quaternions in my games class at university. But it went in one ear and out the other. I didn't understand a word of it. >_<

I'm going to need to try harder hehe.

I agree wholeheartedly, and while we're at it, how about ditching bounding boxes in favor of something more precise?


Hehe well... bounding boxes are ultimately the quickest and easiest method for detecting collisions... Pretty much every game I know still uses bounding boxes for collision and provided the model shape is pretty uniform, it is still possible to get away with it hehe. In terms of player models, a bounding box is still the best alternative (since players move around the most, you want collision to be as fast as possible) though you'd want it to fit the outline of the player better.

But as for map objects, bounding boxes are terrible lol. >_<
I was thinking about what they do in HL2 tho where they have two models laid into the model file: the world model and the physics model.
The world model being what you see ingame, and the physics model being a more simplistic version which is used for collision detection as well as newtonian physics if the model can move.

And while I'm dreaming: http://en.wikipedia....ki/Game_physics


Haha... I've been considering it:

http://www.physicsengine.com/

This physics engine is really sweet. There are a whole pile of free demos on the site, and it is free with the only stipulation being you mention it on the game's splash page (altho every game I know that uses Havok does that as well so it's no huge tradeoff)

I think the hardest bit is threading it through the network code... I want to know how Valve did it. Obviously the objects end location has to be the same on every person's PC (which it might not if the physics are calced locally), but at the same time, sending physics object data over a network could lag it out if not done right.

Then again... maybe it's not too bad. We've already got bouncing grenade physics in Q3... :)

I don't suppose anybody is already working on adding a particle system


JKA and JK2 have one. The theory is basically an extension of the rendertypes in the game code.

If I could just copy the syntax from that, we could then use the JKA EffectsED program to write new effects. mwahaha

In JKA/JK2 tho... the particle system is located completely engine side, which is obviously faster than coding it in the QVM code, so I'm researching how that would work right now.

Either way, it's possible to code it in the QVM code hehe.

or ragdoll physics to Quake 3?

Haha from what I've learnt from HL2, that would be a culmination of the bone system threaded through an IK limit system, threaded through the physics engine.

I want to try... but I need to learn a lot more before I can probably pull it off haha.

But even still... in conventional EF, the majority of the weapons used disintegrate or explode the body... so is it really worth it unless we change the weapons...?

-TiM

#26 TiM

TiM

    Administrator

  • UberGames Admin
  • 3,425 posts

Posted 14 November 2006 - 07:11 AM

Another thing. This is what I realized makes blurring between map models and map brushes impossible to tell.

They did this in JKA and SoF2... so it's possible somehow.

When you shoot players and/or models, wherever you shot them, a bullet hole appears on the model.

This is a pretty stock standard requirement of games these days, but I haven't a clue how it's done.

Nearest I can tell is that the location of the shot is pinpointed on the player's texture, and then using blending modes, the bullet hole is added to the texture as it is added to the model.

It would be very cool, visually, either way...

-TiM

#27 Scooter

Scooter

    The Canon Man

  • UberGames Admin
  • 2,545 posts

Posted 15 November 2006 - 02:37 AM

But even still... in conventional EF, the majority of the weapons used disintegrate or explode the body... so is it really worth it unless we change the weapons...?

Don't forget falling damage. There's way of dieing that don't involve disintegration. It might be a low priority item, but it's at least worth considering.

When you shoot players and/or models, wherever you shot them, a bullet hole appears on the model.

In EF there's burn marks; have you looked in there? I doubt though that the burn marks are using an image file which would be required for something like bullet holes (image of bullet hole with alpha channel transparency). Probably we'll need dynamic shaders or something?

#28 TiM

TiM

    Administrator

  • UberGames Admin
  • 3,425 posts

Posted 15 November 2006 - 03:26 PM

Don't forget falling damage. There's way of dieing that don't involve disintegration. It might be a low priority item, but it's at least worth considering.


Yeah... altho for falling deaths, it can easily be fudged by using a 'hit the ground real hard' animation and doesn't necessarily require any dynamic physics calculations.
In fact, from what I've read, if you can get away with it, you should choose to do this over ragdoll physics as it greatly decreases system cost.

In EF there's burn marks; have you looked in there? I doubt though that the burn marks are using an image file which would be required for something like bullet holes (image of bullet hole with alpha channel transparency). Probably we'll need dynamic shaders or something?


Yeah... although that's map geometry. In that instance, the code spawns a quad polygon with the burn texture applied. HL2 does the same thing on map geometry.

It's a lot harder on models since they're usually too curvey, or they're moving, meaning by default the quad would hover in one place.
As a result, it seems that most games use per-pixel precision to pinpoint where the model was hit and to then apply a wound decal to the player skin.

It's a really common game feature now. Off the top of my head, I know that SoF2, JKA, D3, Q4 and HL2 all have it.

I looked in the SoF2 QVM code base, but unfortunately, all of that code is EXE side.

-TiM

#29 Scooter

Scooter

    The Canon Man

  • UberGames Admin
  • 2,545 posts

Posted 15 November 2006 - 08:25 PM

Maybe James can shed some light?

#30 TiM

TiM

    Administrator

  • UberGames Admin
  • 3,425 posts

Posted 16 November 2006 - 04:30 AM

Maybe... I'll see if I can catch him tonight hehe.

-TiM

#31 Scooter

Scooter

    The Canon Man

  • UberGames Admin
  • 2,545 posts

Posted 16 November 2006 - 08:41 PM

I thought of two more whilst replying to Thilo's latest thread; putting them here too so everything is together.

- surround sound and/or EAX support
- DDS texture support

#32 Scooter

Scooter

    The Canon Man

  • UberGames Admin
  • 2,545 posts

Posted 02 December 2006 - 05:04 PM

Motion blur: http://www.crysis-on...t-on-gaming.php

#33 Scooter

Scooter

    The Canon Man

  • UberGames Admin
  • 2,545 posts

Posted 25 January 2007 - 07:03 PM

Procedural textures:
http://www.bit-tech....ture_Gam/1.html

#34 Scooter

Scooter

    The Canon Man

  • UberGames Admin
  • 2,545 posts

Posted 02 February 2007 - 04:09 PM

Bump Mapping: http://en.wikipedia....ki/Bump_mapping
Normal Mapping: http://en.wikipedia..../Normal_mapping
Parallax Mapping: http://en.wikipedia....arallax_mapping
Displacement Mapping: http://en.wikipedia....acement_mapping

#35 Scooter

Scooter

    The Canon Man

  • UberGames Admin
  • 2,545 posts

Posted 04 April 2007 - 12:02 AM

Might be able to learn some stuff from the FreeSpace 2 Source Code Project.

http://en.wikipedia....ce_Code_Project
http://www.hard-light.net/
http://scp.indiegames.us/news.php

#36 Scooter

Scooter

    The Canon Man

  • UberGames Admin
  • 2,545 posts

Posted 22 August 2007 - 02:02 AM

http://tremor.quaked...om/cleanq3.html
http://q3cellshading.sourceforge.net/
http://xreal.sourcef....net/xrealwiki/
http://gongo.quakedev.com/

#37 TiM

TiM

    Administrator

  • UberGames Admin
  • 3,425 posts

Posted 22 August 2007 - 07:51 PM

This is something I want to look at, but I'm not sure how well it'd really fit with EF...

http://cowboyprogramming.com/?p=34

I also want to get this book. :P
http://www.amazon.co...87812229&sr=8-3

-TiM

#38 Scooter

Scooter

    The Canon Man

  • UberGames Admin
  • 2,545 posts

Posted 22 August 2007 - 08:14 PM

If we can't find a use for it, it's still a good addition to the ioQuake3 engine.

#39 TiM

TiM

    Administrator

  • UberGames Admin
  • 3,425 posts

Posted 30 August 2007 - 07:35 PM

Well... parallax mapping at all would probably aim to add a lot of detail to any environment.

The tiles on the ground in ctf_voy1 and voy2 alone would look awesome with that kind of detail...

But bullet holes haha. Yeah... maybe for Quake III it'd work.

Either way, that's not really a concern of the engine. As long as Vertex+Fragment Shaders are added, it's possible to do anything like that.

-TiM

#40 TiM

TiM

    Administrator

  • UberGames Admin
  • 3,425 posts

Posted 12 September 2007 - 03:49 PM

Awwwwwwwwwww....

This is one thing that's been nagging at me so much... so simple, yet so overlooked haha.

Lightmap overexposure. When a light source is really close to a surface, it usually makes the surface so bright, the detail gets washed out.

Here in HL2 is a great example. It allows for really contrasty lighting, and feels a lot more realistic (at least to me)

EF can't really do this... with r_overBrightBits enabled and the screen set to fullscreen mode, EF ramps up the monitor gamma intensity and lowers the lightmap scale to kind of 'fudge' this effect.
And when in windowed mode, the maximum intensity is simply the texture as normal.

But here... it seems that the underlying texture is being completely bled out... huh.

Hrmm.... there has to be a way to do this lol. In windowed mode as well.
Since HL2 is Direct3D and EF is OpenGL, I'm hoping like hell this isn't a technical limitation...

Although.... does HL2 have a windowed mode at all...? :)

-TiM

Attached Thumbnails

  • washedlightmap.jpg




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users