Not logged in, Join Here! or Log In Below:  
News Articles Search    

Submitted by Gerald Filimonov, posted on March 06, 2001

Image Description, by Gerald Filimonov

Heres a screenshot of my current engine ive been working on for the past year or so.

The core of the engine is based on a BSP tree, and the geometry is imported from .map files that are generated by Worldcraft. Ive written my own set of tools that parse the .map files, create faces for all the brushes, remove all the illegal geometry (i.e. faces that are in solid space, overlapping faces, etc...), calculate the BSP tree and finally perform lighting calculations using simple point lights.

I still have a quite a bit of work to do culling more geometry out of the data set by removing all the faces that are outside of the level, but once i get some code to generate portals this should be a trival task. Once all that is done ill start working on code to generate a PVS and use it to render the scene rather than traversing the bsp tree each frame.

The rendering portion of the engine isn't very optimized right now, and for a reason. Currently im focusing on getting the core engine stuff working, things such as the BSP/PVS code, a better lighting model which may include a switch to radiosity, and collision detection. I did run a small benchmark on the engine running on a P3-1Ghz/Geforce2 setup and i got 160fps with the level shown here (around 900 polys). I expect that once I do rewrite the rendering engine ill get at least 500fps or so. I may in the future release a demo, once i fix up the code to work on various graphics cards other than nvidia's.

This engine is being developed to handle the indoor dungeon scenes for a Everquest type game im working on.

-=[ Megahertz ]=-

Image of the Day Gallery


Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
Scrambled Monkey

March 06, 2001, 06:38 PM

"Are u thinking that famous thing MUST be perfect ?" Actually I like those movies, and I think the film makers did a great job in those cases as far as setting mood with color/lighting. I didn't mention those just because they're famous movies, hell I wouldn't have mentioned Evil Dead 2 if that were the case, that movie cost like $0 to make and is considered more of a cult film than a famous film.

"Don't be so stupid and dumb". Don't be so redundant.


March 06, 2001, 07:03 PM

I think this is pretty damn cool. Athestics aside (thats why we hire artists, damnit!) - you seem to have a very solid understanding of the algorithm tech underlying what you've created, as opposed to just traversing someone elses data structures straight out of a file (*cough* .bsb *cough*)
Can I assume that this is "Nvidia only" because of those insanely high-res ligthmaps you've got going? Wow, that's nice. Seeing you're not using radiosity perhaps it'd even be possible to update them in realtime? Shadow volumes be damned, that'd kick some ass. (Anyone remember the ancient vapourware "into the shadows"?)

As for our foul tempered, opinionated Troll who seems to be wrestling with the english language... Go find a bridge to throw yourself off.

Good work, dude - hope it leads you somewhere.

Jukka Liimatta

March 06, 2001, 07:18 PM

>So what? Why does an IOTD have to show millions of polygons to be >impressive?

No, but 900 drawn triangles on a P3 1Ghz (!) is HARDLY impressive, please! Don't get me wrong, I am all glad for him and that he gets enjoyment from programming as much as I do.

But telling him it is impressive is HARDLY the most productive things to say. I say it again that I am happy for him, don't get this wrong.

I also believe I tried to offer a few reasons/means to improve the performance. If he is changing ALL rendering states, when he hits a new texture/material, this could for example be a bottleneck. State changes are rarely "cheap"-- I did bring this out, didn't I? So why my post was not constructive?

I didn't say he needs million polygons ( actually triangles would suffice ) to be *impressive*. I didn't even imply he SHOULD be impressive anywhere as far as I am aware of.

But 900 triangles per frame is still quite conservative figure, that's a number you'd expect to see from Pentium166 and Voodoo Graphics 4MB. Maybe all my years been wasted and I don't know what I am talking about, apologies for that. But what I said, I felt had to be said. Sorry again for being totally jerk and inpolite.

>He's coding an engine on his own and this is how far he's gotten so >far. That's impressive.

I agree, didn't say it wasn't. Maybe I shouldn't measure others by my old experiences-- I didn't find 900 triangles very impressive even on 486/66 @ 320x200 screen with software transfrom+lighting, and software renderer back in 1994. But perhaps I am just too old, too ignorant and egoistic.

I did not really WANT to sound so negative, but that's my experience on the matter. I agree that we should be encouraging to everyone, and not spread negative attitude around. Also, we don't know anything about the dataset or engine of his, except what I saw on the screenshot + description. I just told my opinion that the code might be improved-- I'm sure he will take the task to optimize the code into his heart now. If not, not because lack of suggestions from me.

That's how I feel about that.



March 06, 2001, 07:18 PM

Wow! i didnt expect to wake up and see 30 posts about my iotd..

To answer some questions:

var:"Nice shot! What do you mean by "lighting calculations"? Do you generate lightmaps? Or do you use vertex lighting?"

Yes im using lightmaps, each lightmap is 32x32.

L.e.Denninger:"You really should up your polycount for your maps.. :)"

This is just a simple proof of concept map. Yes if i wanted to, I could make a huge 40,000 polygon level, but at this time, I feel my time is best spent elsewhere.

vortex:"Very interesting shot. Looks kinda futurisitc for an EverQuest-style game. If you are using a pregenerated BSP tree for your maps, how are you sorting the character's polygons?"

Yeah this scene does look futuristic due to the quake2 textures, in the end i dont know that indoor dungeons will look this futuristic, but that all depends on the theme of some of the areas in the game.

Jukka Liimatta :"900 triangles on 1GHZ P3 + GeForce2 !?!?!?"

Yes thats all the level has and theres no culling being done other than backface culling by opengl. I know the engine is unoptimized, im using 3 Vertex3f calls per poly and doing a texture state change every poly as well. The lightmaps are all on separate polygons. But honestly at this point i dont care. Im more concerned with working on the core of the engine, getting the engine working and then worrying about getting it fast. Im still learning alot as i go along, and optimizing right now is just going to hinder devolpment of the engine.

Phil Carlisle:"Nice work Gerald, I was just curious why you dont actually go for using the .bsp format over the .map? If your going to do bsp/pvs anyway, wouldnt it make sense to use the whole toolset"

Sure, I could have done that, but I really wanted to write everything myself for a few reasons. First, I wanted to avoid any conficts with using tools from id software in the event that this code ever sees the light of day in a commercial game. Secondly, and probabaly most importantly, i would have learned far less by taking that route. It's crazy how much ive learned from doing this project, and what's crazier is how much i know ill still learn from pushing this project even farther.

I see alot of concern that the level is too dark, or its got that dark atmosphere to it. Well first off there IS only one point light in the level above. I do feel however, that in certain areas of this project, such as the dungeons, that they indeed will be dark. I have to agree with the comment about the zombie strolling though the field of daisies, its just not something that would make sense. Im sure the game will have a mix of bright and dark areas, but for now because ive only implemented point lights in my lighting code, this is the result. =)

bit64:"Sweet. So you are only doing the indoor stuff? What happens when the player steps outside?"

Yes im also working on the outdoor terrain engine as well, right now im playing with heightmaps but i may switch to doing an octtree type thing where i dont have to have a uniform grid of polygons, this would allow more contol over the detail of the map and allow for "overhangs" and things such as vertical walls and caves. Im sure this will come with some performance penalty, but i think even still good performance can be wrung from this type of implementation. Thats what im researching right now. Landscape engines are new terrain to me (pun intended =)) and im sure it'll be fun working with them.

-=[ Megahertz ]=-


March 06, 2001, 08:01 PM

What is all this talk about the fps and polycount? Have any of you actually tried to write pvs/light/bsp code? Anyone can kick out a terrain engine that renders with octree's and get thousands of polygons onto the screen, writting pvs/light/bsp code is much more difficult. Also, he specifically stated that his iod was about the pvs/light/bsp code, not the rendering. Please be careful what you critic in these iods, as the author was not looking for an analysis of his frame rate, but rather the tools he wrote to prepare his data. Most people use the .bsp file which is much easier, but he is using the .map file which is much more impressive.

Great work Gerald!



March 06, 2001, 09:06 PM

The way I read his post, he is not saying "My engine maxes out at 900 tris per second", but rather that the level he showed is made up of 900 polys. He made no claim about polygons per second. If you take 900 triangles and multiply it by the 160 fps he is getting that's 144000 per second, which seems pretty impressive to me. And he said, if you read the post, it is not optimized at all. When optimized, he plans to get 500+ fps, or something like 450000 tris per second.

Am I wrong? I don't see him making a single claim about performance here, just that the level he made in Worldcraft happens to contain 900 polygons.



March 07, 2001, 01:14 AM

I agree completely with you Anthracks. He never said a thing about it begin limited in any way. It only says that the level is 900 Polys. Nothing more, nothing less. People need to understand what they read, and not just interpret it.



March 07, 2001, 02:30 AM

Just read about the lighting thing. Quake (in my opinion) used the brown palette 'cause it went with the theme, like Scrambled Monkey said. The brown palette just worked for it. As for the lighting itself, in my experience, setting SourceBlendMode to DestinationColor, and DestinationBlendMode to SourceColor creates a look the same as Quake. The textures get drawn at full brightness, and the lightmaps actually get blended on as Shadow/Light Maps in a single pass, the blackness in the LightMaps stay black, and the blackness in the textures stay black too, nothing gets washed out or blended strangely. As for the shot, looks nice. Are you using Quake type textures? I noticed you doubled up the coordinates a bit to tile them, looks sharper that way, or are the textures already larger?

Sergei Miloikov

March 07, 2001, 05:36 AM

Nice work dude!
Writing geometry compiler from .map to bsp/pvs is not a trivial work for sure! But... as I guess you do that to learn the technology, but not to do something commersial, right? If so, why don't you try something different at the VSD layer - the BSP/PVS thing is so old, so used and sooo boring... I know that the realization is much harder than understanding of the idea behind that technology - but why don't you try to write something new - who knows, maybe you'll come upon something usefull... as example when you compile the brushes into bsp, you may try the Unreal traversal of the tree using s-buffer to determine visible faces, or not to compile the brushes down to convex leafs of bsp, but try to merge some of them getting concave shapes with portals between them and use that portals for culling... or besides that bsp, make an octree and use it for hierarchical culling... there are lots of ideas in VSD and that's the thing that will speed up an engine, not low-level optimizations of pushing tons of polys... I am very pissed off when somebody says that VSD/LOD aren't needed anymore since the latest video chips can handle 100k tris - this is stupid.
And the way you choose the polys you'll draw from the global set is very important indeed - because of that the PVS is so fast approach compared to Unreal one as an example.
Keep coding!

Manuel Astudillo

March 07, 2001, 06:20 AM


I guess that the biggest bottleneck in the engine is those 3 calls to vertex3f per polygon.
Even if some people here is saying that its right not to caring about optimization at all at this stage, I think that having the vertex in array lists cant be called an optimization. In my opinion when designing the engine you have to think about this kind of things too, since its very hard also to create a good render pipeline which places all the polys in proper array lists, etc. It will be quite hard I think to change the engine, the data structures, to remove those nasty vertex3f calls, when you have coded a lot of BSP/PVS lightmaps, shadowmaps functions and classes.
So my advice is that you begin to change your structures as soon as posible to avoid bigger modifications at the end. Because, honestly, 900 polys its really bad, even with not a single optimization. But anyway, I wish you good look and lets see if after some weeks you can surprise use with 50k polys running at 100fps.




March 07, 2001, 06:30 AM

Eyw..! F*ck S-buffer and PVS..! :)
S-Buffer doesn't work with HW too well, and PVS eats memory like my grandmother..

Bsp is still pretty okay for static scenery though.

And hey, could people please quit whining everytime someone *doesn't* say it's the coolest thing they ever saw..?
We've had this discussion over and over again, knock it off please.

When I (and other people) mentioned that we found 900 polys a bit on the low side for the HW he's testing on , that's just an opinion.
We didn't say it sucks, 'cause it doesn't.

Design over optimization is *the* way to go, period.
So Gerald is doing everything exactly in the right order - and that's pretty unique.

> Have any of you actually tried to write pvs/light/bsp code
Most of us have, really.


Soooooo... let's wait for the next wave of rants :)

All your bugs are belong to me.

Jukka Liimatta

March 07, 2001, 06:58 AM

Then it's a darn simple .bsp level to use for testing on a P3 1Ghz and GeForce2 !!!


Jukka Liimatta

March 07, 2001, 07:06 AM

As a gesture of good will, here's URL to a file which allows to read Quake III .bsp files, also supports ZIP and PAK files ( the same thing, actually where Q3A is concerned ;-)


#include <primport/primport.hpp>
using namespace primport;

ImportQ3BSP import( "path/quake3.pak/blah/foo/bar.bsp" );

That's it, then just extract the data from "import" class, it should be pretty straightforward! Have fun writing Quake III level renderer! ;-)

Disclaimer: the code comes as-is, no warranty is given or taken. ;-)


Jukka Liimatta

March 07, 2001, 07:07 AM

As a gesture of good will, here's URL to a file which allows to read Quake III .bsp files, also supports ZIP and PAK files ( the same thing, actually where Q3A is concerned ;-)


#include <primport/primport.hpp>
using namespace primport;

ImportQ3BSP import( "path/quake3.pak/blah/foo/bar.bsp" );

That's it, then just extract the data from "import" class, it should be pretty straightforward! Have fun writing Quake III level renderer! ;-)

Disclaimer: the code comes as-is, no warranty is given or taken. ;-)


Jukka Liimatta

March 07, 2001, 07:16 AM

Thank you that you did not take my post as criticism, but only as a comment, unlike some others. Some people though I was saying that your code was bad, code is not bad, code is good. ;-)

And I appreciate highly the fact that you took the time to write OWN bsp compiler, etc. tools-- that is the hardest part of all things. Any fool can take data someone else made, and render it.

When you look at the code of Quake engine, for example, you notice it is not the "perfectionism" you'd expect, or thought it would be. The genius of mr. Carmack for example is that he DOES what others only talk about-- in otherwords, hard work. And you are obviously hard-working so what I commented on the screenshot of yours does not definitely go against you.

In otherwords: good job. But NOT necessarily for the same reasons some other people said it was. ;-)


Brebion flavien

March 07, 2001, 08:01 AM

MegaHertz: be carefull, i know premature optimization is the root of evil, but in my experience, having a fast rendering pipeline is the hardest part of programming an engine. If you don't design it properly, you'll end up rewriting your renderer 10 times.


March 07, 2001, 08:13 AM

Duh, it's just a BSP renderer. So cool down people...


March 07, 2001, 08:21 AM

cool, i am glad to see that someone else is trying to do the same type of thing that i am. I am in a much earlier stage of development though. Could someone point me to a specification of the quake3 bsp format.

Leon Rauis

March 07, 2001, 09:46 AM

Knowing that I would've put this project on the 'back-burner' after one too many big problems I applaud your work that has brought you this far, all on home-grown tools and code.

Nice job.


March 07, 2001, 10:42 AM

Thanks for the comments guys. =)

Ive read some of the posts regarding the performance and such about the engine and I just wanna take the chance to reiterate what I said earlier about where my effort is being spent. =/ The primary focus of this project right now is getting the bsp/hsr/illegal geometry/portal generation/pvs technology working, its not a concern right now as to whether my maps have 4 polys or 40,000 polygons. Nor is it a concern if the engine runs at 10fps or 1000fps. Yes ill agree, a blazing fast rendering pipline is damn sweet to have, and im sure it's probably a bit difficult to get running fast. But what good is a fast rendering pipline, when the core technology doesnt work properly? Its all about baby steps, get what you have working first, then move on. Having a fast rendering pipline isnt gonna help me fix the flaws with bsp'er or my CSG code, nor will having 10,000 polygons in a level get that lighting code lighthing things properly and as intended.

Also, im not concerned with whether or not this is old technology or not, or if just plain sux anymore, or if its been done a million times. The fact remains that *I* havent done it, and when i do do it ill have something that ive finished and can show other people. Moreso this is a extremly challenging and fun project for me, and im learning an immense amount from doing it. =)

-=[ Megahertz ]=-


March 07, 2001, 10:59 AM

I totally agree with you!!
Somebody had to say that!!

-=- k33p on c0DiNG -=-


March 07, 2001, 11:38 AM

"Also, im not concerned with whether or not this is old technology or not, or if just plain sux anymore, or if its been done a million times. The fact remains that *I* havent done it, and when i do do it ill have something that ive finished and can show other people. Moreso this is a extremly challenging and fun project for me, and im learning an immense amount from doing it."

Damn Straight :) That's exactly the right attitude to have. I wish you the best of luck with this, and your future projects. Keep up the good work.


March 07, 2001, 11:59 AM

Just note: in fact, I'm not against "dark atmosphere" or smth. I do not like if I hardly can see in the screen though. So it's normal to find the best choice.
Just plz do not compare it with "old dark batman movie"... heh.
Image of this IOTD is dark but I do not say that it's bad. I just can't see any difference between it and, for example, quake. And this really can't be that good. When I play onother new game with quake's engine I see just the same stuff ... dunno why. And yes, it's boring.
And quake itself is game with no contents, absolutely. quake3 is the top- it's just a collection of multiplayer playgrounds (But they're colored nice !:))


March 07, 2001, 12:11 PM

With fact that you haven't done it is right. And if you try to do it by yourself is of course respectable.
You're right saying that proper work is more important than speed. However, we need to remember that it's should be project working in real time so if we do not mind speed, it can cause lots of extra work in future.


March 07, 2001, 01:03 PM

Actually, there are tons of resources for bsp/pvs as well. The thing that can be difficult with these is the actually building of the data. Rendering a bsp/pvs is trivial.

True, anyone can render a heightfield, but doing it well, and where it can be applied to a game, is another matter. LODs, streaming of data, collision detection, etc. is where the interesting aspects of it come in.


March 07, 2001, 02:07 PM

STZ, what is the REAL difference between Quake3 and any other competitive sport? How is it REALLY any different than say, boxing, tennis, track, swimming, wrestling, racing, paintball, golf, archery, basketball, football, hockey, rugby, soccer, sailing or baseball?

It isn't.

For any game, the sport is in the details. None of the above athletic sports honestly have a lot of complexity - it mostly comes down to honing fine motor skills and building "muscle memory". I'll admit that for Quake3 and UT, these proverbial details aren't as bountiful as an athletic sport; but they certainly have them.

Athletic sports do have the upper hand, because the actual play is a much more vivid, more visceral experience. Perhaps someday, when neuro-sensory interface hardware is developed we'll find Quake XXVII matches the experience of athletic sports... I can only wait 'til that day. =)


March 07, 2001, 02:29 PM


March 07, 2001, 04:28 PM

I should say that it is slightly different from tennis, but you may have another oppinion :)

Actually althletic sports is quite useful in today's games and especially useful is anabolic steroids.

Wired Al

March 07, 2001, 06:11 PM

The framerate isn't something to worry with 900 polys whether the engine runs at 160fps or 500 fps, because those framerates don't give any clue about the real performance. When we are talking about 10k - 30k polys at a certain framerate then we can discuss about the engine performance. And even then, it is not just the number or the polygons, there are so many things which affect the overall performance, such as the triangle size.

As I understand the author of the picture, there is 900 polys in that level, which means that only a part of it is shown. A card, such as Geforce 2 has a very fast hidden surface removal, so we don't really get a clue on the performance. Like, try sending 1M of off-screen polys to your geforce and you can see that you can still get your awesome fps numbers.

but the performance wasn't the issue here, so keep up the good work!

This thread contains 59 messages.
First Previous ( To view more messages, select a page: 0 1 ... out of 1) Next Last
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.