Graphics engines was RE: [MUD-Dev] Jeff's Rant: A World Full of Wheel-Makers

[Daniel.Harman at barclayscapital.com]

> -----Original Message-----
> From: Brian Hook [mailto:bwh at wksoftware.com]
> Sent: 22 May 2001 23:15
> To: mud-dev at kanga.nu
> Subject: Graphics engines was RE: [MUD-Dev] Jeff's Rant: A 
> World Full of
> Wheel-Makers

>> Of course not using BSP means that the gfx quality is generally
>> below peoples expectations.

> Actually, that's technically not true.  A BSP is just a form of
> spatial organization that has some handy properties, but over time
> its relevance has diminished greatly.  I would actually be surprised
> if any modern engine heavily relied on a BSP for, say, visible
> surface removal or even collision.

Thats actually quite interesting. I guess I need to go and read up on
3d engines again :) I'd assumed that BSP surface removal was still a
very useful technology, although I was aware of several other
collision detection methodolgies.

So are there alternative culling methodologies used, or is the
tendancy to brute force things more these days? I remember starting to
write a ROAM based outdoor component and after about a days work,
someone on the DirectX mailing list pointed out that brute force was
probably faster that transforming the mesh - NVidia have an article
that supports this. It kind of took the wind out my sails :)

Having said that Black & White looks like it has a ROAM engine in it,
although I hate the way it blends in vertices, it looks like there is
a permanent earthquake shockwave occuring near the clipping plane.

One thing that BSP engines always seem to do better is
lighting. Perhaps its because a lot of it is pre-calculated. Engines
like NetImmerse just seem to have very flat and uninspiring
lighting. Some people think quake/unreal style lighting is over the
top, but frankly I love it!

> These are far more significant problems than interior vs. exterior,
> because the trade offs are tricky and controversial.  If you want
> stencil buffer shadows or long distance viewing without Z-buffer
> artifacts, you can pretty much kiss Voodoo3 support good bye.  If
> you want Dot3 bump mapping support, then you can kiss TNT/TNT2
> support good bye.  And while you hear the mantra of "scalable!  Make
> it scalable!" repeated over and over, the reality is that you can
> scale the technology but not the content.

Scaling the technology has to be a pain too surely? If you base an
engine on pixel shading, then having to support non-complient chipsets
must be a whole world of pain.

I rather like Justin Abashir's python object model that he mentions on
those papers linked to on this list the other day. Where in game
objects are hierarchically associated with each other and linked to
their own geometry (if they have any). Certainly works well with a
scene graph methodology and I would expect it supports development of
the game mechanics whilst remaining graphically neutral for as long as
possible.

Then again, last I heard, scene graphs weren't considered optimal
enough to really base a game on them. Be nice if they were though :)

Dan

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev