quake 3 engine going open sources

John Carmac, the creator of the quake engine, announced that he will soon release the q3a sources code under the gpl license. As an amateur developer and rendering engine fan, I find the open source announcement exciting. Hopefully this will lead to further innovations in rendering. The original quake engine was the foundation for many different rendering engines. In-fact even today, q1 sources code can still be found in many games.

This code could even effect SecondLife Development. It could bring more competition into the arena. Maybe it will influence the developers of SecondLife, and as a result we could end up with a much more efficient rendering engine. What do you think?

I love this engine,and the fact that top selling games like COD were being made with it up till 20 odd months ago shows how robust and flexible a solution it is.Going OS is good for all engine coders everywhere.Telefragalicious

Wow, a new toy to play with

I think this is great. The Open Sourcing of Doom was really cool. A lot of people made great stuff with it. And it runs on Everything. Q3 was killer too...



This I doubt. Turning a multiplayer game into a streaming massive multiplayer virtual world is no trivial task. Besides if LL developers stare at a gpl'd rendering engine for to long, they might be forced to gpl thier own rendering engine

However, without a doubt, this will influence independent game developers and Open Source render engine hackers. Q3 ran on Linux, so this is exciting. Maybe indies will create more FPS mods and total conversions for Linux! Imagine a bootable CD that just had a bunch of great free multiplayer FPS games.

Don't know if the rendering engine would be helpful now, but id has always been said to have good network code.

However, I suspect the same roadblock that's always been an issue will stop indy game types from using this: the BSP compiling. I haven't kept up with it in almost a year, but last I checked there was still no level-editor that used an open source compiler to generate the BSP file. Perhaps this will spur some development (or maybe the initial announcement that this would be GPL'd last December has already yielded a tool).

[Edit: Sure enough, there appears to be a compiler finally: http://www.osmanturan.com . Whether it works with an open source level editor like QuArK, I don't know. ]

I haven't had any trouble developing q3a levels before.. on os x no less.

Define developing.

Building a level in radiant, then compiling the level, and then successfully loading the level in q3a.

No offense, but this has nothing to do with SL

The Quake3 engine relies 100% on geometry pre-compiling. SL, on the other hand, has to make do with everything on-the-fly. If you told Quake3 to do that, it would choke, die, vomit on your floor, and then turn into some sort of undead vomit thing.

SL cannot, and will not be able to pre-compile ANYTHING in the world, unless you want to lose the ability to edit those objects. Which most folks wouldn't go for. EVEN THEN, Arranging those items any way you want would still strain the rendering engine in such a way that you wouldn't be able to precompile it anyways.

This is like comparing apples to vietnamese tactical warfare. Totally different things.

LF

I wouldn't call that developing. I'd call that making a level for Q3.

I'm talking about indy games being developed using the soon-to-be GPL'd Q3 engine. Just because the engine is open source, doesn't mean the tools are. Among those tools are the level editor (*Radiant) and either the original q3map compiler or Ydnar's version (which utilized portions of id's code iirc) which convert the .map into a bsp. And from the little research I did after finding that link I found to an open source compiler (above post), it appears to have its issues as well.

In any event, for on the fly rendering check this out: http://www.projectoffset.com . Hard to believe that's being rendered in real time. Now THAT would be something to see in SL.

Why? They both are good when burnt to a crisps!

Yeah, any modern gaming engine like G3, HL2, wouldn't like something dynamic like SL too much. What we really need is some kind of workable compromize, like that ability to 'prerender' certain things, and only edit them when necessary, and still offer dynamic objects.

Haha, Lordfly, can I sig that?

While it is true that q3a take advantage of pre-compiling; it's also capable of rendering dynamic polygons. It's just a change in the objects parameters. In fact some people have already tried it. While it slows down the engine; it isn't crippled. Most p.c. user now own machines that let them play q3a at 300+ fps, switching every thing to a dynamic materiel type drops the frame rate down around 80.

The q3a engine has no problem with rendering multiple levels of transparent textures, on-top of each other. The engine also supports hundred of style of rendering. It also support a large verity of hardware and software, and fallow a very OOP to it's design.

Sorry, shenanigans. Show me an uncompiled, 100% dynamic map being played in quake3 at anything more than 1 frame a second... it's just not possible

Quake3 runs fast because it has a ton of optimizations beforehand. Remember vis, Qlight, and qbsp? That's the compilers for the map, that also run optimizers for light and visualization fields. The engine knows where you can be, and also knows where you can't be... thus cutting out 80% of calculations.

SL doesn't have that luxury. Ever.



We're not talking dynamic material, we're talking about "hey, I want to build a house using infinitely scalable primitive shapes." The Quake 3 engine can't do that on the fly.



The rest of this is just buzzwords.

It also shifts the paradigm, don't forget that.

LF

I just can't resist.

In late 1969 the NVA distributed 3600 tons of Chinese and North Korean apples to its own units and irregular troops in South Vietnam and along the Cambodian border. Rice balls and forage game did not give the soldiers a "complete" diet, and the "apple" effect was immediate: troop health and morale improved considerably. In early 1970, the NVA was able to begin a series of small tactical offensives against ARVN and U.S. forces two months earlier than planned, and NVA/irregular soldiers performed far better than expected. The NVA continued to distribute apples, limes from South America, and a few Cuban oranges among its units for the remainder of the war, with large numbers being given out before starting a campaign.

Apples and tactical warfare in Vietnam were the same thing....

OK, I'm done being a smart-ass.

You know, that is a good theoretical idea:

What if you had the ability to 'bake' buildings, and have them pre-processed with lighting and other calculations. When set to bake, all of the lighting, texturing, blah-blah-blah would be complied like a script during times when the sim was less active.

Is it worthwhile? Probably not, but the idea is interesting to contemplate.

The problem is things like depth calculations. For example, LL can tell that this wall blocks everything else out.

Can Quake do that dynamically? Kurt says 80 FPS, Lordfly says 1.

It would be interesting to find out who is right.

Actually they can't, because nothing is compiled; the client has absolutely no idea where you will be 5 seconds from now; you can be anywhere within a 256x256x768 cube. If they could predict this (clipping maps, portals, etc.), this wouldn't be a problem.


Can Quake do that dynamically? Kurt says 80 FPS, Lordfly says 1.

It would be interesting to find out who is right.[/QUOTE]

The original quake engine (and i imagine Quake 3) had a program optimizer called "vis"; basically it calculated all possible angles that the player could be in and optimized the renderer to only render certain polygons at certain times. It took hours for a large level (several times smaller than your average sim), often using simple polygons.

If you didn't do that... yeah, the map would run, but it was severely degraded, ugly as sin, and prone to polygon clipping (the renderer was rendering too many polygons at once, so it arbitrarily drew a visual cutoff line).

So we're back to square one.

LF

Are you talking about SecondLife or Quake 3? I was talking about Secondlife and saying that they could do this dynamically. The question is can Quake 3 do it at 80 FPS?

Your argument is that they can't. Can you cite your evidence? Can anyone link to anything in this conversation? I'd really like to read some further discussion on this.

What keywords can I google on? I tried "dynamic polygons" +quake .. no dice.

Doesn't quake need some dynamic polygons because things move around in quake? It has to work to a certain degree, doesn't it?

Talk to Ydnar. If anyone knew whether an uncompiled .map would run at 80FPS he's probably the best to answer that. afaik he still maintains the compiler for id.

[Edit: you can on rare occasion find Ydnar over on the http://www.map-center.com forum.]

Done.

That is incredible news and cannot wait to play around with it.

Lordfly Digeridoo,
There is nothing buzzy about Multiple layers of transparency. It's quite common for designers to layer 3 or 4 transparent textures on-top of each other. Being able properly render under those circumstance, is some thing q3a can do and sl can not. In one of the public interviews, a ll staff member said they would fix this bug when they figured out a quickly way to properly render under those circumstances. It couldn't hurt to take a peek at q3a, and see what john carmac did. Maybe it will inspire, or give them ideas of function or recursive algorithm they have yet to try.

One way q3a cuts down on rendering is allowing the level designer to define visible areas, and being able to simply the collision model of complex areas. In theory sl could use these techniques.

iirc, Q3 is per-polygon collision. As the level geometry is part of the compiled bsp tree data, the clipping tools - if that's to what you're referring - are also non-dynamic. They're effectively "baked in". Since SL's geometry is dynamic, I don't see the similarity wrt collision. Perhaps I don't understand your point in this regard.

More to the mix.