What are you working on?

[toneddu2000]

let's talk about that! How much is "high poly" for you? For me, in 2012, high poly is a scene with 200.000/500.000 tris (not polys) at time. How much tris can handle DP or FTE(not stock Quake) per scene? This really interests me

[Chip]

[ceriux]

chip im really excited about your engine, i know your going for a not so feature rich version of dp. but what kind of features WILL your engine support?

[Chip]

[hogsy]

[Chip]

[toneddu2000]

what about deferred shading/realtime GI, Chip? It seems that big companies had left HDR to its destiny

[leileilol]

I don't understand the stripping as a lowly Pentium II can still handle a fully featured Darkplaces build.

[goldenboy]

A P2 may be able to handle Darkplaces, but what about running any meaningful content?

[leileilol]

[goldenboy]

nah, just that Chip may have other purposes in mind than running id1.

[mh]

I've experimented some with deferred shading in Quake, just rendering to multiple targets and combining them in a final pass. I didn't do anything special like real lighting, I just grabbed the standard lightmap data and spat it out as is to the lighting target. My impression is that it has it's own overhead which is quite significant - even this simple setup dropped framerates to one fifth of their previous. On the other hand this is a clear tradeoff; you accept this kind of framerate drop in exchange for better handling of multiple lights in a real lighting setup.

So for traditional Quake lighting it's not viable. For realtime lighting, it will give you the lights but not shadows (you still need a separate shadowing solution for that). There are probably certain breakpoints beyond which it's better than forward-shaded realtime lighting, and it will very likely run much better than DP without .rtlights files, but as a general-case solution for Quake it's not something you want to do.

[Spike]

defered lighting: http://sparkgame.net/media/screenshots/fte00015.jpg
sure, okay, there's no shadows, but that's still running at >72 fps.
each spot is a separate entity, although they're not particuarly optimised in that shot.

defered shading/lighting are awesome when you have 10k+ poly models - you no longer have to draw the mesh once _per light_. Well... I guess you may still have to do shadows - yay for shadowmapping sunlight - depth only passes with no triangle extrusion/culling/etc. But yes, the fact that you're now rendering to multiple buffers and then reading that back etc does have overheads. Overheads that are quite acceptable in certain situations - like lots of lights.
The true joy of it is that you can draw (unshadowed) lighting using a single quad. Using stencil shadows or shadow mapping will give you only the extra overhead for the shadow volume/shadowmap - the actual light is just a single quad that doesn't care what the underlaying geometry is.
For small light sources that have no shadows, its awesome. Just think if each individual spark from your gunshot was an independant light source, etc.

But yes, quake's general geometry level is not complex enough for deferred shading or deferred lighting to be a win.
Although from a code cleanliness perspective, it makes rtlights so much more sane!

[toneddu2000]

I think the most important question is: "what next gen quake derivated engines should be useful for"? I mean, if all the (I think HUGE) efforts programmers from all over the world had to face to realize their own engines are useful only to run Quake or Quake 2 I humbly presume it's too much work. Even because, if you think about it, Quake original engine was good enough to do what it should have to do in '96. Instead, if the new faboulous engines present today (FTE,DP,Super8,RMQ'S and many others I didn't mention because I can't remember all) can be used ALSO to make NEW games I think some new toughts should be done. Does it still need BSP format? Can be more useful a Blender/Maya/3dSMax file importer where graphic/level designers can create their levels with modern tools, without sticking to grid and cubish measures? Does lightmaps still need? Couldn't be replaced by full dynamich lighting + GI? And most of all: are derivated quake engines powerful enough to realize 2012 games? I said that because I'm using DP to create a game and I'm struggling every day to decide if is this the right way or to head to Udk o Unity. I'd like to know also Motorsep's opinion, because he realized 2 games with DP and he's making the third with it!
Don't take my post as trolling, it wasn't meant to be

@Spike: is it Fte? Cool! How to enable it?

[goldenboy]

Any near-future project I might do will highly likely use BSP to create basic layouts, not meshes, since it is fast and simple and I'm good at it. I just use mapmodels/props where BSP isn't enough. The problem is not BSP or Radiant vs. Blender (in fact Radiant still is one of THE best tools for making levels), the problem is mainly in lighting, especially lighting outdoor areas, wanting brighter light (more contrast), dynamic sunlight / sky, and proper lighting of models/entities so they don't stick out visually compared to BSP.

Needless to say, BSP29 (ie the Quake map format) is problematic, but not brushes themselves as long as you can use models along with them (.obj/.iqm). Vis I could do without (areaportals or something would be preferable, or at least working detail brushes).

I have nothing against Quake based tech as long as I can make stuff in Radiant / Blender and have it displayed correctly. Performance should be adequate, and personally I'm willing to keep using (higher res, preferably) lightmaps (with a few dynamic lights strewn in) for performance reasons. You can make very good looking environments in engines like Quake 3 and Source (eg. Sock's maps) without normal mapping etc. And what matters in the end is the gameplay and the idea of the game. Stunning photorealistic environments aren't necessarily needed, just good-looking ones.

Be aware that using Cryengine etc. will require more time/resources for making assets - personally I'd rather put that time into actual gameplay, modeling, animating, GUI, sound and 2D art and just be content with Source/Q3 level visuals. Making e.g. HUD elements and sounds for Cryengine is pretty painful, whereas you can simply use TGA/DDS and WAV in Quake based tech. The complexity of the workflow matters.

My problem with Darkplaces atm is performance - FTE and RMQE run circles around it. My problem with the more traditional Quake engines is lack of basic features. There must be a middle ground where you have some features and OK lighting without sacrificing all your performance. Something like Source.

http://www.simonoc.com/pages/design/con ... ecrane.htm

No Cryengine was needed for this.