Doom 3 engine release and game code

My best guess no different than mh's but if you are in eu you should be safe.
Btw i noticed something odd with my update packs which basically breaks stuff if unlucky. There to big for Doom3's pak handler it seems so if you get a weird error about undefined stuff its probably due to this (game crashes).
If you get the above unpack the zpakxxx.pk4 and repack them with 7 zip in zip mode on ultra. It should work then but the best fix is splitting more stuff up so that this doesnt happen.

A big warning: even if you're in the EU, if your project is hosted in the US, or if you post patent-infringing stuff on a US site, the site and it's owners may still be liable, or your project host may be required to kick you.

hmm dunno if google's server is in US domain i have to look that up besides it seems a lot of projects allready adapted your code ouch :S from the tip of my head iodoom raynors fork logicalerrors fork hmm...
im trying to write ttimo on github about it (id developer) maybe he can shed some insight.

looks like it was allready brought up https://github.com/TTimo/doom3.gpl/issues/3

its a bit unclear still but it looks to be allright since libade made an implementation much like mh's but with the older non gl2 seperate stencil.
btw his version uses depth clamping on the shadows also which im also using

ok, the only thing I understood is that, to avoid legal issues, is better to use carmack code!
Because, even if you leave in the EU, as I do, if you want to sell a game worldwide, you could encounter the same problem.
But, sorry for my ignorance, is it so bad carmack new code for shadows?
Why become necessary to override it? Is it slow, ugly or what?
It would be great to make a youtube video with the 2 versions in comparison

PS: unfortunately I tried to download the file from your ftp, but after 10 h of download(20kbs speed average), it stopped working thanks anyway for your kindness!

it may have been because im running chkdsk on the drive that went corrupt (uses a lot of resources) it should be ok now. or use an ftp client many free ones and they support resuming the downlad
if you are unsure about the code my uodate pack works with standard unmodified doom3 code also (its all shader based).

carmacks new version without the legal issue isnt terribly slow its just us coders who want to pull the fastest best optimized code on a modern card its neglible even.

You could use two-sided stencil with the original code easy enough and there are no patent worries about that. That would halve the fillrate overhead of shadow volumes, but in the Doom 3 implementation the bottleneck is on the CPU not the GPU so it's not that big a deal. At the same time, it seems the sensible thing to do.

Going for the GL2 two-sided stencil implementation (with possible option fallbacks to the EXT and ATI versions) would make sense. It is 2012 after all.

The patent issue doesn't cover that part of it; it covers the z-fail algorithm.

In the common case there is no patent issue - the view is outside of the shadow volume and you can just use normal z-pass. That's a two pass draw with regular stencil (i.e. the released code) or a one pass draw with two-sided stencil (i.e. the original engine or a GL2 mod).

The special case is when the view is inside a shadow volume and that's where the patent issue comes up. In that case your options are to risk the wrath of Creative's lawyers or to play safe. I recommend playing safe, which means it's four passes with regular stencil or two with two-sided stencil. That only applies to drawing any shadow volume that the view is inside; all other volumes (view is outside) will still be drawn as I outlined above.

In normal gameplay it's not tha big a deal. On reasonably modern hardware you probably won't even notice any performance difference. You can pick scenes in the game that do show it up (like the dropship shadow at the very start) but otherwise it's highly unlikely to be ever even happening, or happening for more than 1 or 2 shadow volumes, on any given frame.

There are other things in Doom 3's renderer that are a much more significant performance drain anyway (VBO setup, skeletal animation on the CPU, clearing the stencil buffer in isolation, etc) so time is better spent tackling them rather than worrying over shadows.

when the glsl backend is fully working it should be possible to move even more stuff to the gpu
raynors code is fine but it has a drawback in comparison to the arb2 backend in that the arb2 backend uses a struct to hold the different shader types while the glsl backend does it's thing directly and so is missing a function to load material shaders.
im looking at some code that i might be able to adapt to achive that. prey uses a glsl backend and i hope to make something that rivals its functionality.

thanks guys for the technical clarification, now it's a lot much clear. Now a provocation: nowadays is it more advanced an engine like Darplaces/Fte (which derived from an '96 engine but they're still developed in 2012) or Doom3 engine (which is an 2005 engine, written in a completely different manner, c++ against c, but "old" respect DP and Fte)?

'advanced' is subjective. vanilla doom3 doesn't support glsl, while fte+dp both (ab)use it as much as they can, so in terms of renderer features, yeah, the '96 derivatives win...
but there's two things not available to the q1 derivatives, and that is ragdoll and code to invoke that ragdoll (thus tying the entire world into a single cohesive physics system). I really cannot express how important that is for a modern FPS.
Yeah, you can create ODE objects, but frankly I still personally only see that as a gimmick feature rather than something you can base a full game upon. Both engines are capable of drawing skeletal objects in pretty much any pose, but there's no code that actually uses it and thus its pretty much useless to the average person around here.

an engine is nothing without a purpose, and doom3's is much more focused upon that purpose, thus what is there is much more useful.
that said, doom3 has a max player limit of 4 or something stupid... which is more of a joke than a real attempt. so yeah, its all subjective.

and that is ragdoll and code to invoke that ragdoll (thus tying the entire world into a single cohesive physics system). I really cannot express how important that is for a modern FPS

That still astonishes me. Spike, I ask this question to you and LordHavoc, who are two of the "pillars" of the quake community:
Is it really so difficult to integrate a REAL physics engine (like Bullet) into quake?
I noticed that every experiment I did with ODE is laggy and imperfect.
There's no "consistence" in the physics system.
IMHO it should need:
1) a skeletal motion system (locomotion system, head tracking system, weapon detachment, and "body consistence" like Euphoria or Sumotori dreams instead of ragdolls - see this video and this video to understand what I mean!)
2) a quakec reference easy and well documented to move skeletal objects
except those 2 points I consider DP and FTE a very robust game development platform

the old mdl format uses a rather simple animation system so ragdoll effects will by example look less than optimal but if you base a game on some of the skeletal formats either darkplaces or fte supports then i guess its a whole other ballgame
tbh im not totally certain from what data the physics code gets its data but im pretty sure its not from QC. besides ODE physics one could try bullet (i heard it works quite well in other engines ) .

the old mdl format uses a rather simple animation system so ragdoll effects will by example look less than optimal but if you base a game on some of the skeletal formats either darkplaces or fte supports then i guess its a whole other ballgame
tbh im not totally certain from what data the physics code gets its data but im pretty sure its not from QC. besides ODE physics one could try bullet (i heard it works quite well in other engines ) .

Bullet is derived from ODE. The issue with Bullet is that it is C++.

Btw we've had working ragdolls in Alien Arena for over a year now, using ODE, and it is not "laggy" at all.

The critical thing about Doom 3 is that it's designed very heavily around the hardware of it's time, and the limitations of that hardware. Because it's quite tightly coupled to a fairly specific hardware spec, it's moderately non-trivial to push it into anything more advanced or modern.

Quake by contrast is almost a clean sheet of paper (as is Quake 2, to a lesser extent in some places but just as much in others). It's so primitive that all it takes is a coupla days work to start moving forward from it's baseline. The only really messy parts of it are the QC interpreter and the netcode, and a lot of problems with working on them just go away if you're prepared to break compatibility.

bullet is derived from ODE ? ok didnt know that. hmm wrap the c++ calls ?.
not sure whats causing the lag with ODE toneduu mentioned, could be a number of things.