BZN bsp renderer.

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 20

BZN bsp renderer.

Post by mkultra333 » Sun Mar 07, 2010 7:42 pm

The final goal is to make a game using the Quake 3 Arena game source code, with Ogre doing the rendering. This is just the first step in that project, which is rendering the bsp with modern shaders. This is strictly brushes and patches, no models yet. License will be GPL, since that's what the Q3A code is.

I've been working for 1 year now, going by when I registered on Ogre. I had hoped I could release source code and a map to go with it, but I've run out of time and too many details need to be fixed, so it'll be another week or two before that, but I figure I should at least post a few screenshots.

The maps are constructed using a customized version of Dark Radiant, and compiled using a customized version of Q3Map2. Both of these are GPL.

Image

The lighting model is a hybrid of deferred shading, non-shadowing point lights (called "lamps" in the code) and forward rendered, shadowing spotlights. At the moment there is no ambient lighting since I like that stark, dark Doom3-ish look. However I may add an ambient pass with some kind of SSAO, depending on how things go.

The deferred shading lamps come in 1-pass and 2-pass varieties. The 1-pass are faster, but the 2-pass allow for fake shadow volumes to be built, so that simple shadowing from non-moving geometry can be built into the map. This is a bit labour intensive, and mainly intended for prefabs where the effect might be handy. For the most part the 1-pass lamps will do fine. The deferred shading lights are fairly fast, though I wish they'd been a bit quicker. I'm not using MRT, just a bunch of RTT, so that's one avenue to speed them up a bit.

The shadowing spotlights come in 2 varieties, faster and slower. The faster lights are just typical VSM shadowing spotlights. The slower lights are the same but have the ability to be coloured as they pass through things like coloured glass. Here you can see the light being coloured as it passes through the red glass.

Image

The spotlights are all automatically capable of projecting textures as well.

The .map format I use is slighty different from standard Q3A maps, it's closer to the doom3 format in the way it defines brushes and texturing. The resulting .bsp is also different from the standard Q3A bsp, though not significantly. A few parts have been removed (such as lightmaps) and some other parts added (the specification of the zone/portal bounding boxes). Also the light entities are defined differently. This incompatibility was unavoidable, but it would not be hard to convert an old bsp to this new format. Here's a quick run down of the differences, from the code.

Code: Select all

// The lump idexes that make up a bsp file.
// Bzn bsp lump data is almost identical to q3a bsp lump data,  except that the
// Effects, Lightmaps and VisData lumps are removed and there are two new lumps, one
// describing the subzones and one describing the portals. The other difference is the lighting
// entities (which are stored as normal entities in lump 0) since q3a bsps don't usually
// store the light entities at all, and BZN has it's own unique set of lighting keys.

const int Textures = 1;
const int Planes = 2;
const int Nodes = 3;
const int Leafs = 4;
const int LeafFaces = 5;
const int LeafBrushes = 6;
const int Brushes = 8;
const int BrushSides = 9;
const int Vertices = 10;
const int MeshVerts = 11;
const int Effects = 12;				// removed from bzn
const int Faces = 13;
const int LightMaps = 14;			// removed from bzn
const int VisData = 16;				// removed from bzn
const int SubZoneData = 17 ;	// added to bzn: overlapping subzones form zones. Zones are like groups of axial boxes.
const int PortalData = 18 ;		// added to bzn: portals overlapping different zones allow them to see each other.
The bsp rendering is mostly complete, but there's still a long way to go as far as finishing the overall project goes. It's taking a while... hopefully it will speed up a bit once I start integrating the Q3A game code.

Image
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Re: BZN bsp renderer.

Post by jacmoe » Sun Mar 07, 2010 8:38 pm

Looks like a great pipe-line! :D

I'd be very interested in seeing the code for this, when it's ready. :)
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

dudeabot
Gnome
Posts: 334
Joined: Thu Jun 28, 2007 2:12 pm
Location: Brazil
Contact:

Re: BZN bsp renderer.

Post by dudeabot » Sun Mar 07, 2010 11:47 pm

wow very interesting :)

how would this compare to the perfomance of next generation games? id say that the quality is nearly the same :D but i've heard BSP partitioning is old now, what do you think?
0 x

User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
Contact:

Re: BZN bsp renderer.

Post by Praetor » Mon Mar 08, 2010 12:17 am

Really like your results. How much of the BSP system remains at runtime? Is the BSP just a format for storing the level or do you do actually use the structure for partitioning during rendering?
0 x
Game Development, Engine Development, Porting
http://www.darkwindmedia.com

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 20

Re: BZN bsp renderer.

Post by mkultra333 » Mon Mar 08, 2010 6:22 am

Jacmoe:

Thanks. I should warn you, my coding ain't pretty. A lot would be at home on Daily WTF. I've used a lot of other peoples code as a starting point, a DX9 bsp renderer I found in google code (no shaders or modern lighting though), Nullsquared's soft shadows, and Nvidia shader code. Most of it is modified almost beyond recognition.

JustBoo:

My intention is to make commercial first person shooter games. Q3A might seem an odd choice, but I like the engine and I've used it a fair bit before, it's a toy I'm familiar with. Every time I try other engines they always fall short of what I want and don't have the visual or gameplay feel I want. I wasted 6 weeks of last year going off on an Ureal3 SDK tangent. In the end I could not get the kind of lighting I wanted, and I found the engine and what was required to make a game painfully convoluted, so I went back to my project.

I intend to make content the focus, to think of content as the thing being sold. Since the engine is GPL, people can get and compile the engine for free, but the content is still copyright and people legally have to pay for that. Not that they will in practice, hehe, but that's the ideal.

dudeabot and Praetor:

For the renderer, the bsp structure isn't really that important. I could change the current render to use some other map format without too much trauma, all my render expects is to be handed a bunch of sorted triangles and entites at load time, it constructs the map and then it's game over for the bsp structure, I even delete it from memory before rendering the first frame. Culling is handled by a zone-portal system rather than the vis data. The .map compile doesn't even do a vis or lighting pass.

However the bsp will still be important once I add the Q3A game code, since that code works against the info in the bsp. For instance, bots look at the world as a bsp. The stuff I've removed, the lightmaps and vis, aren't used in the game code either. Speed should be fine, since this engine was constructed to run on hardware from 11 years ago, and it ran fine back then.

Id bsps also have some nice properties from a mapping point of view. They collapse unnecessary polygons, and they eliminate T junctions. And I like the style of map that tends to come from mapping in a BSP fashion. I will update it to include more models though, and probablyl have to add additional collision detection to cover those models. I'd like to add something like Bullet to the game, mainly just as an effect for particles, flying rubble and maybe some ragdolls.

Edit:

I should probably give some idea of current performance. I'm using an nvidia GT7950 which is getting a bit old by modern standards. I run at 800x600 on the assumption that people with better cards will up the resolution for the same framerate. When the project is finished I want it to run at least 30 fps during heavy scenes and 50-60 fps typically. To accomplish that you probably want no more than 3 spotlights and 20 deferred lights visible at any one time, less if they are the slower variety. At the moment that'll get me 50-60 fps. But a lot of the scene and a lot of the post processed FX aren't there yet, so I'll have to watch it closely as I add things, to see what I can really get away with.

It isn't as fast as I'd hoped it would be, but hopefully it won't be too sluggish either.

I'm still on Ogre 1.6.4 too, I'll update to 1.7 soon.
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 20

Re: BZN bsp renderer.

Post by mkultra333 » Wed Mar 17, 2010 12:22 pm

I've quickly scrambled together a small map and zipped up the exe and the source, it can be downloaded here: http://www.mediafire.com/file/tokcc5d3t ... 00317a.zip. The source in the "BZNBSP_100317a" folder expects to output the exe to the "BZN" folder.

The map is pretty rough, but at least it's something to look at. Turns out I could have more deferred lights than I thought, I was just making them too big before, so I've scattered them around fairly liberally. At the moment the map is running with the slower version of the spotlights to show colourization through glass, even though only a few of them are going through glass. Ideally whether a spotlight is fast or slow should be set in the map editor or worked out at run time.

While running you can press "m" to change the display mode, it'll cycle through wireframe, hdr, the various deferred renders, then back to the full render. Wireframe is good for seeing the zone/portal system working.

Two more things, you start below the floor, outside the map, so you'll have to fly up a little to get inside. And if you look closely at the reflections you see a family having a picnic in the country on a sunny day... this is the result of space madness.

Here's a few more pics just for the hell of it.

Image
Image
Image
Image
Image
Image
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
xadhoom
Minaton
Posts: 973
Joined: Fri Dec 28, 2007 4:35 pm
Location: Germany

Re: BZN bsp renderer.

Post by xadhoom » Wed Mar 17, 2010 2:13 pm

Wow, you created some very nice shading techniques. Which of the spot lights are actually casting dynamic shadows?

xad
0 x

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 20

Re: BZN bsp renderer.

Post by mkultra333 » Wed Mar 17, 2010 2:22 pm

Thanks xadhoom. All the spotlights cast dynamic shadows.

The difference between the two types of spotlights is that they can be set to either be coloured as they go through glass (and render slower), or just to ignore glass (and render faster). The code in the download is hardwired to make all the spotlights the former, slower kind, though it's just effectivly a bool setting to choose between the two, in the code just change "int nColouredShadow=1 ;" to "int nColouredShadow=0 ;" to see the difference. I just haven't added the lighting key in the map editor to control it yet, the two kinds can be mixed in the one scene.
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 20

Re: BZN bsp renderer.

Post by mkultra333 » Wed Mar 17, 2010 3:41 pm

I should probably point out another thing. At the moment there aren't any doors. Doors would cover a lot of the portals and mean the zones beyond wouldn't need to be rendered, which would help the framerate.

You can see how many spotlights and zones are being rendered printed out on the Ogre overlay, as "Lt: n Zn: n"
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
xadhoom
Minaton
Posts: 973
Joined: Fri Dec 28, 2007 4:35 pm
Location: Germany

Re: BZN bsp renderer.

Post by xadhoom » Wed Mar 17, 2010 4:41 pm

mkultra,

I just wanted to compile everything (using the 1.7 SDK) and I´ve run into a mutex runtime crash (debug) when loading the raw file testmap06.bsp:

Code: Select all

>	BZN_Engine.exe!boost::detail::basic_recursive_mutex_impl<boost::detail::basic_timed_mutex>::lock()  Line 49 + 0x5 bytes	C++
 	BZN_Engine.exe!boost::unique_lock<boost::recursive_mutex>::lock()  Line 350	C++
 	BZN_Engine.exe!RawFilePtr::RawFilePtr(const Ogre::SharedPtr<Ogre::Resource> & r={...})  Line 45	C++
 	BZN_Engine.exe!RawFileManager::load(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & name="testmap06.bsp", const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & group="Raw Bsp")  Line 41	C++
 	BZN_Engine.exe!OgreFramework::LoadMap()  Line 2823 + 0x35 bytes	C++
 	BZN_Engine.exe!DemoApp::startDemo()  Line 43 + 0xb bytes	C++
 	BZN_Engine.exe!___sse2_available_init()  + 0x2240 bytes	C++
 	BZN_Engine.exe!___sse2_available_init()  + 0x22c8 bytes	C++
 	BZN_Engine.exe!__SEH_epilog4()  + 0x13 bytes	Asm
Any idea why he stops here? Your precompiled runtime worked fine...
0 x

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 20

Re: BZN bsp renderer.

Post by mkultra333 » Wed Mar 17, 2010 4:50 pm

I never use debug, so haven't run into this.

I needed to load the bsp from a zip and treat it as a raw binary file. Not knowing how to do this, I created the RawFile, RawFileManager and RawFileSerializer based on an ogre Wiki article on making custom resource loaders. I must have done something wrong.

Hopefully this won't be a major issue. I've read there's a simpler way to load raw data into ogre, but since I had a system in place I never followed it up.

Does the release mode build ok?

Edit: Oh, wait, you said 1.7. I should point out this is 1.6.3, so an incompatibility may have come up. I'm intending to move to 1.7 soon but have been busy getting other stuff together.
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
xadhoom
Minaton
Posts: 973
Joined: Fri Dec 28, 2007 4:35 pm
Location: Germany

Re: BZN bsp renderer.

Post by xadhoom » Wed Mar 17, 2010 5:01 pm

Hmm, no release leads to (probably the same) crash like debug. es I´m using Ogre 1.7. Might be that there are incompatibilities.

Did have a look at the deferred shading demo recently. Might be interesting in case you want to use Ogres inbuilt compositor pipline in the future...

xad
0 x

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 20

Re: BZN bsp renderer.

Post by mkultra333 » Wed Mar 17, 2010 5:17 pm

Since you don't need to build the dll's, it's probably the headers that are the issue.

Sorry, I should have said it was 1.6.3, I forgot all about that. I'll have to make updating to 1.7 a priority. In the mean time, people can still run the exe.

I didn't use the compositors (or the inbuilt shadowing) because I wanted to make sure I had total control, due to an impending stereoscopic rendering mode. If rendering systems aren't made specifically to cope with stereo they often don't work.
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
xadhoom
Minaton
Posts: 973
Joined: Fri Dec 28, 2007 4:35 pm
Location: Germany

Re: BZN bsp renderer.

Post by xadhoom » Wed Mar 17, 2010 5:24 pm

Ok. I know what you mean. Just in case you find out that its worth to use the "wheels of others" here you can find a stereo solution for Ogre es well.

BTW: Do you have any performance comparison information between BSP and Ogre generic scene manager? Regarding that I´m also glancing towards CHC++ ;-)
0 x

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 20

Re: BZN bsp renderer.

Post by mkultra333 » Wed Mar 17, 2010 5:35 pm

The stereomanager is cool, but AFAIK it doesn't handle deferred shading. I'm aiming at compatibility with a multitude of stereo drivers too, such as nvidia and iz3d. That's for later though, I've just done a few preliminary tests to make sure I'm on the right track. :)

As far as performance goes, I'm pretty much using the default manager anyway, with zone/portals on top of that. I don't really use the bsp for culling or anything, it's just there to be compatible with Q3A.
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 20

Re: BZN bsp renderer.

Post by mkultra333 » Fri Mar 19, 2010 3:58 am

Glad you like it. As far as the content goes, for now I've decided to do it all myself. I'll summons the best programmer art I can, I figure if I stick to robots and monsters and avoid realistic things I'm in with half a chance.

It'd be nicer (and faster) to use real artists, but until I can afford a real lawyer I'm wary of it. :)
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

dudeabot
Gnome
Posts: 334
Joined: Thu Jun 28, 2007 2:12 pm
Location: Brazil
Contact:

Re: BZN bsp renderer.

Post by dudeabot » Fri Mar 19, 2010 12:46 pm

i tried to run in a "onboard" Intel video card here at job, it crashes with "cannot allocate a Hardware Query"
0 x

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 20

Re: BZN bsp renderer.

Post by mkultra333 » Fri Mar 19, 2010 1:07 pm

Yeah, that isn't surprising, I tried it on my netbook and it didn't run for the same reason. It needs the hardware occlusion queries to solve a lag issue at lower frame rates (http://www.ogre3d.org/forums/viewtopic.php?f=5&t=50486). It also uses a lot of RTT textures. The card needs ps_2_x or arbfp1 fragment shaders too.

The rendering is fairly heavy duty, so your typical low spec laptop card won't work.

Edit: There are some things I could do that might get around the need for HOC, but I don't know if it would help, the program would probably still crawl on a typical laptop graphics chip, so it'd be kind of pointless.
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 20

Re: BZN bsp renderer.

Post by mkultra333 » Fri Mar 19, 2010 2:38 pm

As a rough guide, if you've got less than an Nvidia 7900 then it probably isn't worth trying the program.

I use a 7950GT at 800x600 as my bench mark. People should change their resolution so they're getting at least 30 to 40 fps in the slowest scenes. People with cards twice as good as a 7950GT can try 1024x768, and so on. I worked all this out at one point, the best hypothetical resolutions for a bunch of different cards, but I seem to have lost the document. Suffice to say people with the latest cards should be able to run it at very high resolutions without problems.
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 20

Re: BZN bsp renderer.

Post by mkultra333 » Sat Mar 20, 2010 4:07 am

Ah, found the document, it was on my netbook.

Estimated relative speed of BZN renderer on new and old graphics cards.

Benchmark is an Nvidia 7950 GT at 800 x 600 resolution.

Speed is roughly how much faster the renderer would run at 800 x 600 resolution.
In brackets is the resolution that would run roughly as fast as an Nvidia 7950 GT at 800 x 600.
Values at this stage are guesswork based on published relative benchmark speeds found at
http://www.tomshardware.com/charts/grap ... rds,1.html

There is a large margin of error at this stage.
________________________________________________

Speed x 8.0 ( 2560 x 1600, 8.533 more work)

Nvidia Geforce GTX 285 SLI (2x1024 MB)
ATI Radeon HD 5970 (2x1024 MB)
________________________________________________

Speed x 6.0 ( 1920 x 1200, 4.8 more work)

Sapphire HD5870 1G GDDR5 (HD 5870 1024 MB)
ATI Radeon HD 5870 (1024 MB)
Nvidia Geforce 9800 GTX+ SLI (2x512 MB)
_________________________________________

Speed x 4.0 ( 1680 x 1050, 3.675 more work)

ATI Radeon HD 4890 (1024 MB)
Nvidia Geforce GTX 260 216SPs (896 MB)
ATI Radeon HD 2900 XT CF (2x512 MB)
Nvidia Geforce 9600 GT SLI (2x1024 MB)
Nvidia Geforce GTX 260 (896 MB)
ATI Radeon HD 4870 (512 MB)
________________________________________________

Speed x 2.0 ( 1280 x 1024, 2.7306 more work)

ATI Radeon HD 2900 XT (512 MB)
Nvidia Geforce 9600 GT (512 MB)
ATI Radeon HD 3870 (512 MB)
Nvidia Geforce 8800 GTS (320 MB)

________________________________________________

Speed x 1.5 ( 1024 x 768, 1.6384 more work)

ATI Radeon HD 4670 (512 MB)
ATI Radeon X1950 XTX (512 MB)
______________________________________________

Speed x 1.0 ( 800 x 600, Standard GPU work)

Nvidia Geforce GT 220 (1024 MB)
ATI Radeon X1900 GT (256 MB)
Nvidia Geforce 7950 GT (512 MB)
Nvidia Geforce 7800 GTX (512 MB)
ATI Radeon X1800 XT (512 MB)
_________________________________________________

Speed x 0.5

ATI Radeon HD 2600 Pro (256 MB DDR2)
Nvidia Geforce 7600 GT (256 MB)
_________________________________________________

Speed x 0.333

Nvidia Geforce 6800 Ultra (256 MB)
ATI Radeon HD 3470 (256 MB)
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

x3n
Gnoblar
Posts: 7
Joined: Mon Jun 16, 2008 1:59 am
Location: Zurich
Contact:

Re: BZN bsp renderer.

Post by x3n » Tue Mar 23, 2010 5:54 pm

This looks awesome! :)

I'm currently working on a project and I'm interested in using your code to render BSP maps in our game. We already talked by PM about that ;) but I also have some questions which might be of common interest, so here we go:

- You say you're using your own rendering system for shadows and compositors - is it possible to add an option to use the inbuilt compositors/shadowing instead?
- I see you have a lot of shaders in your map, for example normal maps, reflections, HDR, etc. What about old graphics cards? Are there any fallbacks or is it possible to disable certain rendering passes?
- Again about the shaders in your map: Do you use the default material format which is used in Ogre or do you use Q3A shaders?
- You mentioned fake shadow volumes - are they generated by the editor, on startup or dynamic while playing the game?
- Is this all built upon the standard Ogre classes or did you modify some of them?
- Is it possible (or planned in the future) to add meshes, particle effects and other stuff to the scene? Will they also be affected by the zone culling and lighting/shadow casting?
- You mentioned doors to increase performance, but doors are usually not included in the BSP map - will they cover a portal just the same?

Forgive me my curiosity ;) But this looks just too good to ignore.
0 x

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 20

Re: BZN bsp renderer.

Post by mkultra333 » Tue Mar 23, 2010 6:11 pm

- You say you're using your own rendering system for shadows and compositors - is it possible to add an option to use the inbuilt compositors/shadowing instead?

Maybe, I don't know. I wrote most of this on 1.6.3 and ran into issues with the standard shadow code, so I got around them by making my own shadowing using RTT. Maybe 1.7 gets around those issues, but it's a moot point for me since Ive got my own solution. I especially don't know if the colourized shadows are possible.

As for compositors, again I don't know. To be honest, I don't much see the point of compositors once you can do RTT. I just do my post processing and other effects with RTT and shaders. :)

- I see you have a lot of shaders in your map, for example normal maps, reflections, HDR, etc. What about old graphics cards? Are there any fallbacks or is it possible to disable certain rendering passes?

The shaders need 2.x or better shader model language, as said above. The shaders could be re-written for lower spec cards but you'd lose a lot of the point. You might be able to make them 2.0 and not lose too much.

I might make a version to run on netbooks too, with very simple shaders that run fast but will probably look worse than the original Q3A. Handy for people who just want to do some multiplayer free-for-all on the train. But for the time being the engine is aimed at the x1.0 speed cards or above that I posted before.

- Again about the shaders in your map: Do you use the default material format which is used in Ogre or do you use Q3A shaders?

I use Ogre format materials. And most the textures are in compressed DXT format.

- You mentioned fake shadow volumes - are they generated by the editor, on startup or dynamic while playing the game?

Neither, you have to manually build them in the editor. They aren't intended as the primary shadowing effect, just for small localized effects on the deferred lights.

- Is this all built upon the standard Ogre classes or did you modify some of them?

Standard Ogre classes.

- Is it possible (or planned in the future) to add meshes, particle effects and other stuff to the scene? Will they also be affected by the zone culling and lighting/shadow casting?

I'm working on meshes at the moment, just got the first rough results today. They get lit the same as everything else, shadowless deferred lights and shadowing VSM spotlights. It's a bit tricky because meshes can have sub meshes with different materials, and materials are already a headache in a deferred shading scheme, but I think I'm getting it under control.

- You mentioned doors to increase performance, but doors are usually not included in the BSP map - will they cover a portal just the same?

Q3A maps can and do often have doors. They'll be built in the editor and drawn in the renderer.
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

x3n
Gnoblar
Posts: 7
Joined: Mon Jun 16, 2008 1:59 am
Location: Zurich
Contact:

Re: BZN bsp renderer.

Post by x3n » Thu Mar 25, 2010 2:31 pm

mkultra333 wrote:I might make a version to run on netbooks too, with very simple shaders that run fast but will probably look worse than the original Q3A. Handy for people who just want to do some multiplayer free-for-all on the train. But for the time being the engine is aimed at the x1.0 speed cards or above that I posted before.
Just an idea, but you could maybe use the standard lightmaps on old systems?
I'm working on meshes at the moment, just got the first rough results today. They get lit the same as everything else, shadowless deferred lights and shadowing VSM spotlights. It's a bit tricky because meshes can have sub meshes with different materials, and materials are already a headache in a deferred shading scheme, but I think I'm getting it under control.
Are your problems with materials related to the fact that you implemented the rendering by yourself instead of using the inbuilt features?
0 x

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 20

Re: BZN bsp renderer.

Post by mkultra333 » Thu Mar 25, 2010 3:11 pm

Just an idea, but you could maybe use the standard lightmaps on old systems?
It wouldn't be too difficult to add them back, but at this stage I don't plan on doing that for two reasons. Firstly, the size of the final bsp file is smaller without them, and my plan is to have a lot of maps in my final game, which will be a download, so smaller is better. The second reason is that I quit the Unreal Development Kit because its lighting model was so convoluted, so I don't want too much convolution in my own game.

Perhaps a third reason is that graphics cards are getting better all the time, so it probably won't be too long before virtually any computer can run the BZN renderer as is, even small netbooks. I do have plans to make a "turbo" mode though, that basically renders the game at an even lower resolution for a boost in framerate.

In a way it's just a matter of taste, I can see how lightmaps would be handy in some situations, but I've decided not to use them because I want more dynamic lighting. (Another thought is that if you add back lightmaps, you probably need to add back the "lightgrid" as well, which is how Q3A lights dynamic models. That's both more size in the bsp and more programming to light stuff.)
Are your problems with materials related to the fact that you implemented the rendering by yourself instead of using the inbuilt features?
No, it's more a general factor when you do deferred shading. It isn't a problem, its just a little bit of work and organization. I've fixed that, so meshes are rendering now, I just need to add the zone/portal culling for entities, which I don't expect to be difficult since it's almost the same as the code that culls the spotlights. Here's the standard Ogre robot, albeit with a new material.

Image

On a side note, I have run into a weird issue with OpenGl performance. It is being very inconsistent, sometimes it's almost as fast as DX9, but other times it crawls at only half the speed. I'm mainly aimed at windows anyway, so it isn't a catastrophe, but hopefully I can find the cause.
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 20

Re: BZN bsp renderer.

Post by mkultra333 » Wed Mar 31, 2010 11:11 am

Got to try my renderer on a friend's computer today, it's pretty new, Windows 7 and an Nvidia 9800GT with two monitors. It was the standard story: The program that works fine on my setup crashes to oblivion on a different one.

D3D9 crashed on startup, it doesn't like how I've got the hardware occlusion queries set up. Fortunately I've since programmed it so they can be turned off. Once deactivated the program ran fine. I'd estimated it'd run twice as fast at 800x600 and was pleased to see it ran three times as fast. But without the HOQ the irritating input lag issue reappeared. I'll have to do some work on getting the HOQ working properly.

OpenGL was a different story. It had no problem with how the HOQs are set up, but instead of rendering on the main monitor it rendered on the second (sideways) monitor. When I ran at a higher resolution, it actually rendered on the second monitor PLUS put the extra screenspace onto the side of the main monitor. So a bit of a mess. OpenGL was not as fast as D3D, it was twice as fast compared to three times as fast. But then given the messed up monitor situation I won't take that as canon.

So I'm guessing that a few of the people who've downloaded the demo have run into similar issues. Not running on laptops that don't support HOQ is expected, but crashing on cards that do support HOQ is not. I'll have to work on it.
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

Post Reply