Jump to content
The Dark Mod Forums
Sign in to follow this  
RPGista

IDTech 4 engine - what for?

Recommended Posts

So I was reading one of those "vs" articles between Doom3, HL2, Farcry, etc. It seems that at the time (maybe even today), Doom3 impressed all with the dynamic lights mechanics, but fell short in most of other factors of compelling gameplay. The engine seems to be plagued by the game's design choices, of persistent pitchblack darkness and hallway gameplay, that bans complex outside areas completely. Someone posted an article that says adoption of the engine after it going open-source has been pretty low (http://www.phoronix.com/scan.php?page=news_item&px=MTIzMjU). Since Im a total illiterate in terms of gaming technology, and thinking about all the available "free" engines (some more than others) that are available today, like Unreal's, Unity, etc, I was wondering what would be the point of using IDTech 4 today? Or saying it in another way, what would be the type of game or situation where you guys, that know about this (GameDevGoro, Serpentine, etc) or simply like to follow these things, would see as the perfect reason to use Doom's engine instead of another? Is it really a modern engine you could base your indie game entirely upon nowadays? For what kinds of games?

  • Like 2

Share this post


Link to post
Share on other sites

The problem I see with IDTech 4 is definitely, as you pointed out, that the way Doom3 is doesn't exactly warrant the engine to handle a lot more.

Engines like Unreal, Source and maybe even Crytek are better* (Having said that, Source, Crytek and Unreal all have their flaws that are equally unpopular.) in that they scale better to larger or smaller environments.

Doom3's engine hampers itself by using an old culling method that only really works ideally in narrow corridors as seen in Doom3, most modern engines that I'm aware of actively choose to replace this method and use newer and less "effective" methods. (If anyone wants I can try to explain more thoroughly.)

 

I'd say TDM, for example, lends itself to IDTech 4 pretty well seeing as how it is mostly indoor. But for another kind of game, like an openworld RPG or the like- IDTech 4 would be disaster.

 

 

* usage of the word "better" is solely within the context. I'm not saying that one engine is better than the other. It's very important to understand that engines all have their own pros/cons and very few/none are equally balanced.

 

Note: My unbiased view of the engine(IDTech 4) is that I wouldn't choose it. Just as I wouldn't choose any of the other IDTech engines. ID's engines are great at what they do and boy they do it fast. But part of Carmack's design philosophy seems to be to sacrifice flexibility in order to gain speed. This is a paraphrasing of what he's at one point said, his real words are something like: "If you're willing to sacrifice flexibility, you can almost always do something better" I don't recall it verbatim so for the love of good don't take that to heart, I don't really know if he at all adheres to this regarding his engine designs, but the engines he's made indicate that it's sort of true. ID's engines aren't very flexible. And I'm not one programmer to do anything magnificent with them even if I had the entire codebase sprawled at my fingertips.

Edited by GameDevGoro

Share this post


Link to post
Share on other sites

Exactly, part of my doubt was, would an indie game creator adopt IDtech4 for an oblivion like rpg game, for example, or maybe an starcraft/diablo-like isometric game? Would it make sense? Doom has some really awesome TCs so the potential is definitely there, just take a look at Hexen, TDM, Grimm or Arx. It would be the perfect engine for a recreation of Severance Blade of Darkness too, a sword fight melee game that had awesome dynamic lighting (there is people working on it, actually). But if a commercial engine that has a lot of technical features becomes available like that, and people dont really use it, it left me wondering...

 

GameDevGoro - I thought your engine experiments were pretty cool, by the way, what was your intention with it? What did you want it to achieve, if I may ask?

Share this post


Link to post
Share on other sites

Id Tech 4 is a victim of bad timing.

 

It was too early for good OpenGL shader language drivers.

It was too late as a dynamic lighting engine as UE3 arrived shortly afterwards.

It was too early to have a good DX9 hardware base to run it well.

It was too late to be relevant to the high-end DX7/8 hardware market it originally targeted.

 

If your goal is to do dynamic lights with good performance, deferred rendering is the most efficient method

currently available.

 

The engine had a brief moment of glory where no other immediate mode renderer could do what it could do

but was surpassed (in the industry) very quickly.

 

That said, the engine does have some great long-term aspects.

 

1) The renderer is fairly well compartmentalized meaning that various components of it can be switched out.

For example: Intel did a tech demo where parts of the renderer were Ray-Traced.

 

2) The Unified material and lighting model is very forward thinking. Unreal Engine 4 will have this feature and it's

considered a natural future development of engines. Having a single pipeline that handles all lighting and material

aspects rather than various hacky scenarios where you must script transitions from one model to another is

definitely a "good thing".

 

3) Pathfinding is volumetric. Most engines do not handle spacial pathfinding scenarios (that said, this is also a

possible caveat as you need to monsterclip away areas in all axis to prevent extraneous processing in unreachable

vertical areas.)

 

4) Unlike some modern Deferred Renders, Doom 3 does not squeeze all the light material data into a small buffer

which can produce numerous artifacts and aliasing. All the materials render pretty much WYSWYG. Yes, normal map

compression is problematic but there is a fix forthcoming...

 

Id Tech 4 does just about everything a modern renderer should do and has very few legacy style hard limits.

If you have the hardware, you can scale-up the detail.

 

The biggest pitfall is that it is just less efficient than current renderers that do the same stuff.

It does just about everything, it's just slower at it.

 

That could change if something like Tr3b's Light Indexed Deferred Renderer ever comes out. Then it would make

the engine comparable efficiency-wise to Crytech or UE3 but with the added value of it's unified material system making

it a fair competitor to even UE4.

 

 

 

The easy way to think of it:

 

Immediate mode renderer means "As soon as it's fed a triangle, it renders to the screen buffer"

 

Deferred renderer means "Gather up either lights or geometry in a buffer then evaluate which lights or triangles get rendered based

on what the buffer determines".

 

1) Old engines (Quake 3 and earlier) = Baked light. Tricks to occasionally show light changes

 

Immediate Mode renderer

 

2) Doom 3 = Fully Dynamic light with normal maps to reduce geometry storage

 

Immediate Mode renderer

 

3) HL2 = Baked "Radiance" (step backwards) with normal maps to reduce storage

 

Immediate Mode renderer

 

4) UE3 = Dynamic Light* and Baked light with parallax maps to reduce geometry storage.

 

(*deferred renderer.)

 

The Dynamic lighting in this engine is a bit hacky and requires a lot of mapper intervention.

 

5) Crytech = Dynamic Light* and Dynamic Radiance with normal maps, parallax maps or POM to reduce storage

 

(*deferred renderer)

 

The dynamic radiance in this engine is a bit hacky and requires some degree of mapper intervention (though the tools cover over these problems mostly).

 

6) UE4 = Doom 3 style unified Lighting with unified Dynamic Radiosity

 

(Deferred renderer)

 

The final destination. Everything is unified into one interface. Everything is dynamic as with the real world.

 

----

 

HL2 became so popular because it tackled the most practical problem. How can we make scenery and animated objects live in the

same light model. How can we cheaply approximate radiosity (which is the predominant light that is visible in most scenes).

 

Most games don't need to have flashlight or torch wielding AI searching dark corridors as a primary game mechanic so making

a fully dynamic engine was not a priority for most of these companies.

 

 

I think the engine has a future if it's shown just enough attention.

 

Even if nobody retrofits the engine to use deferred rendering, there are still areas that can be tweaked and improved.

 

And, of course, hardware keeps getting better too.

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

@nbohr1more: I completely agree with you, but there's still a few things I'd like to point out:

 

HL2 vs Doom3 is an interesting situation-

They both came out at about the same time- the same year. 2004.

So I'd like to think of the situation that both stem from similar engines. Doom3 and id tech 4 follows the technology from Quake 3 and actually has some of the code still in there and Half Life 2 and Source follows Gold Source from Half Life 1 which is a blend between id tech 1 (quake engine) and id tech 2.

 

So by that fact HL2 and source *are* at the time of release inferior to the technology shown in Doom3.

 

But.

 

We should ask ourselves which one of these two enable developers and modders to create the most variation in environments (this makes all the difference when a developer or modder sits down to choose an engine, it's all about the range of possibilities and what's used most often):

 

Half Life 2 uses baked shadows and radiance, fact. But the inherit softness of this allows the organic (natural) environments in Half Life 2 to look just softer and less "plastic" as has been the gripe from many mouths concerning how Doom3 looks.

You can't, however, create hard shadows with source (I know the later versions of source actually have shadow rendering from lightsources, but this is at the time of launch). You can have characters cast fairly hard shadows, but the baked maps will always have that fuzzy softness. But this isn't that big a drawback. Most lighting we see in our physical world is soft due to light bouncing and doing its thing.

 

Doom3 has only hard shadows, hard enough to poke ones eye out. This has a very specific application. It works in Doom3, sure. It fits the mood.

That's why most Doom3 mods looks so rigid and unnatural, again to use the word tossed around Doom3 so often- plastic.

It doesn't lend itself well for creating environments or even characters that look organic and soft.

Personally my biggest gripe is the shadowing. Shadows don't look that way. Shadows look this way when you've got extremely dark areas with strong artificial lighting. Obviously no one would want "strong artificial lighting" in an outdoor level, right?

And my observations extend to other games that used similar shadowing, like our very own favorite: Thief: Deadly Shadows.

The important difference, however, is that TDS never used specular maps. They faked it by using cubemaps. It worked out better I think, everything in the game looked softer and more organic thanks to this.

 

Now if, like you pointed out, we could replace Doom3's lighting with a deferred system we could by the fact also replace the hard shadowing to something softer, but this is not something that's easily done. But it would likely be faster as hardware advances and geometry shaders can further be used to render a multitude of shadowmaps without redrawing the geometry of the world.

Then we'd have something that stands a real chance if the artists are good enough, good artists are actually key why many games that are technically inferior appear in better light than others, it's easy to forget this when you get bogged down in "engine world".

 

Last jab: Another part of why Doom3 often looks unnatural, even in environments that try to be natural and organic is that it uses a constant ambient lighting term. Modern engines often use diffuse cubemaps or spherical harmonics for this, and boy does it help.

 

 

 

Lastly...

GameDevGoro - I thought your engine experiments were pretty cool, by the way, what was your intention with it? What did you want it to achieve, if I may ask?

 

My intention is simply to learn how engines work and get to a point where I am free to write games without necessarily using an existing engine/framework. I'd say I'm actually at a pretty good point now, but since I'm complete self-taught I'm struggling when it comes to knowledge of popular algorithms and such. I'm not really aware (unless I learn it of course) what popular algorithms do what and how, so a lot of times I've implemented something a certain way, not knowing that there's a much more efficient way of implementing it. So a lot of my learning is still in the fine print, the large aspects have mostly been dealt with.

I'm right now working in UDK with a bunch of people, but I'm still tinkering with my engine. :)

Share this post


Link to post
Share on other sites

I think we should stop talking about id4 engine and talk about the Dark Mod engine, since at this point we are a new engine that has its own advantages over Doom3. And if someone were thinking about an engine to build off of, I'd recommend they branch off of Darkmod than start from scratch with Doom3.

 

Of course we inherit a lot of things that are the same, like the lighting engine. All things considered, I kind of like the unified lighting of id4 in terms of a game being a good reality-sim, WYSIWYG. There's no fake shadows or different categories of light; there's all the same system of projection and shadows. I don't like when some engines fake the soft shadows and I figure it out.

 

That said, of course I'd be happy if the shadow-softening algorithm for doom3 could be efficient enough for real time (right now it's only good for screenshots; it looks great though! So at least you can have great looking soft-shadow screenshots of scenes in Doom3/TDM).

 

I also wish it had radiosity since that makes such a huge difference in the reality of a scene IMO. But I recall reading that that may be in the cards for us in the future, now that we're open source. That'd be great!

 

Those two things are really the only two things I really, really want, soft shadows & radiosity. Well, we could use realistic havok physics too. Doom3 already comes with multiplayer code, but it doesn't survive well in branch projects; so I wish we had multiplayer for TDM too. But as a general engine feature,soft shadows & radiosity are what would make our engine the best for other game projects wanting to build off something.

 

For me personally, another factor is just the fact I've worked with TDM long enough that I know it's quirks, and I feel comfortable getting into its guts (the fact it's open source & I can get into anything I want makes me happy too). So I don't relish starting with another engine from scratch. But that just applies to me, not generally.


What do you see when you turn out the light? I can't tell you but I know that it's mine.

Share this post


Link to post
Share on other sites

I think we should stop talking about id4 engine and talk about the Dark Mod engine, since at this point we are a new engine that has its own advantages over Doom3. And if someone were thinking about an engine to build off of, I'd recommend they branch off of Darkmod than start from scratch with Doom3.

 

Sure. Were it that people actually use the engine at all. Part of this discussion is to contemplate why developers and modders choose not to use id tech4 at all.

And you guessed it, without a wider adaptation and people willing to use it on a larger scale, we won't see that much change unless we do it ourselves. :mellow:

 

For me personally, another factor is just the fact I've worked with TDM long enough that I know it's quirks, and I feel comfortable getting into its guts (the fact it's open source & I can get into anything I want makes me happy too). So I don't relish starting with another engine from scratch. But that just applies to me, not generally.

 

No one's suggesting that TDM should switch engines (other than the occasional kid that sign up on these forums and tries to motivate the developers to "put it inside crysis 3"), that would be the biggest waste of time and talent this world would ever see.

Build off from what we have... not reinvent.

Share this post


Link to post
Share on other sites
No one's suggesting that TDM should switch engines (other than the occasional kid that sign up on these forums and tries to motivate the developers to "put it inside crysis 3"), that would be the biggest waste of time and talent this world would ever see.

Build off from what we have... not reinvent.

 

I wasn't suggesting it either. I wouldn't dream of it. I was thinking from the perspective of a new team wanting to make a new game and what kind of engine they should choose. (That's what I thought this whole topic was about.) If I were on that team, I'd pick the TDM engine (even for something quite different, like a platform game) for a number of reasons, but one being because I know the engine really well. It's a way to say I'm admittedly biased.

 

But my general point was that even aside from my admitted bias, I still think a new team should pick the TDM engine for a lot of types of games they might want to make, not HL2, Not Crisis 3, and not id4 (some of my point also being that the TDM engine != the Doom3 engine anymore).

 

Edit: I mean, I wish people would NOT use vanilla id4 because it's getting dated an backwards now. I would much rather they branch off of TDM. Every time I see a new id4 project reinventing the wheel, I quietly sigh & wish they had found out about TDM and branched so they could actually contribute something, instead of wasting all the time for (inevitably) inferior systems nobody can use. If they build off the TDM engine, then we can move the ball forward.

 

I think I'm making the same basic point you are from another angle.


What do you see when you turn out the light? I can't tell you but I know that it's mine.

Share this post


Link to post
Share on other sites

Yeah, the AI work alone plus the melee system and use of lights/sadows would make it worth it to branch from TDM, and Im sure there would be other engineering reasons too. For an action rpg game in the lines of dark messiah (im yet to play it though), TDM would be the perfect base, challenging melee, physically accurate world (in terms of what can be seen or heard), responsive AI...

Share this post


Link to post
Share on other sites

PS: gamedevgoro, cool project, good luck with that, you guys have quite a talented artist!

Share this post


Link to post
Share on other sites

I'd say TDM, for example, lends itself to IDTech 4 pretty well seeing as how it is mostly indoor. But for another kind of game, like an openworld RPG or the like- IDTech 4 would be disaster.

 

Prey 2 is using a modified version of idtech4 and it's open world. *gulp*

Share this post


Link to post
Share on other sites

Prey 2 is using a modified version of idtech4 and it's open world. *gulp*

 

Prey 2 isn't even released yet.

I'm not saying that id tech 4 can't be modified to do these things- I'm saying it's likely it will never happen because no one gives two farts about the engine despite it being open source. :huh:

Also, Brink uses a heavily modified version of id tech 4, I think it looks/works just dandy.

Share this post


Link to post
Share on other sites

Yep wolfenstein 2009 also uses I'd tech 4 and handles large open areas just fine. Of course that version of I'd tech 4 uses a deferred renderer (as does Brink). Though wolfenstein seems to have suffered most from packing data into the gbuffer... Textures were blurry as hell and the "detail texture overlays" are often laughably ugly...


Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

The engine I'm looking forward to playing with is Voxel Farm, for the same reason I like modding for Minecraft sometimes. It procedurally builds a world for you and has a natural LOD but you can modify the world so build buildings and structures, and probably place monsters & NPCs. So it'd be really cool for making standard adventure maps. And it should have standard RPG/adventure stuff out of the box (fighting, inventory, readables, etc).

 

I mean it's the same thing Minecraft is doing right now, but it's hard to get over everything being boxes. But in Voxel Farm, it's a very Skyrim looking world, hills, valleys, forests, pillared caves, villages, blended textures, grasslands, deserts, snow, etc. If the engine is also as open & mod-friendly as Minecraft (which he's promising), a modder can also make a lot of the gameplay features to their own ends. I just like the idea of making an adventure map where the engine takes care of the world out of the box, and I can focus just on the buildings, and placing objects, readables, & AI. (I'd still keep playing with Darkmod though, of course. Nothing that moddable competes with its gameplay IMO.)


What do you see when you turn out the light? I can't tell you but I know that it's mine.

Share this post


Link to post
Share on other sites

Yep wolfenstein 2009 also uses I'd tech 4 and handles large open areas just fine. Of course that version of I'd tech 4 uses a deferred renderer (as does Brink). Though wolfenstein seems to have suffered most from packing data into the gbuffer... Textures were blurry as hell and the "detail texture overlays" are often laughably ugly...

 

Maybe that's what we need... A TDM open area contest to see what is possible. People are assuming it is not possible with TDM, but we should explore what can be done!

 

For an outside area, the majority of lights could be noshadows. They would work just fine and the mapper would use only a few shadows casting lights for the most critical spots. Can lights be turned noshadows based on LOD player distance? This would be important as well.

 

Alternatively, all the objects around lights could be noshadows, except the biggest and gameplay-important objects.

 

It would also be a LOD useage lesson. With the magnificent DR ase exporter, mapper could easily make a bunch of different LOD models of their architecture. The architecture could easily be very detailed when the player is near it and ultra-low poly from the distance.

 

Fog could be used along with func_portals to compartmentalize scenes a bit.

 

The only problem I see is the AI. I wish they had LOD models. They take around 3000 tris (right?), which is dreadful waste of detail when the AI is far away, and there really is some kind of FPS killer limit with the number of AI that could hang around in the open area, all visible at once. Can the AI be hidden based on distance? This would help if some fog was used.

 

Suddenly I'm very thirsty at trying to map something open.


Clipper

-The mapper's best friend.

Share this post


Link to post
Share on other sites

There's a function to dynamically hide & unhide an AI (I think it's even called "hide" IIRC), which stops and starts it rendering (but doesn't stop it being there). I was playing around with it for spawning an AI, but he'd still make noise & walk around while invisible, which was dumb so I dropped it. But for the purpose you just mentioned, it'd be perfect. And where there's a function, there's S/R or scriptability, where you can rig it to proximity to the player.

 

The best approach to portalling open areas that I know is the kissing circles technique that Trail of Blood used & Badcogg used in Left for Dead. Build large oval "rooms" made out of some rocky or woody material, hide as much of it as you can behind vegitation, and have the ovals meet at kiss-points that you portal over. So one oval could have 3 or 5 kiss points (at the right angles so you can't look through more than two portals in a row standing at any one place), and there's a great interlinking web of them; then the whole network ends up being organic, chaotic, and natural looking.


What do you see when you turn out the light? I can't tell you but I know that it's mine.

Share this post


Link to post
Share on other sites

I don't think the # of polys is the issue with AI...it's their thinking that slows things down.

 

If someone can demonstrate that it would provide significant savings, I could make low poly versions.

Share this post


Link to post
Share on other sites

So one oval could have 3 or 5 kiss points

 

This sounds better and better! :wub::laugh: (I'm sorry, I know quoting out of context sucks, but this was pretty funny I think.)

 

But in all seriousness, the portaling system really isn't ideal or even favored for outdoor areas which is another reason why I think id tech 4 is so restrictive in what types of games are made with it.

But there's really no way to change that for our purposes (and really- we don't), but may be worth considering when we get into a discussion about why developers don't use it. All I'm suggesting is that we keep this in mind and respect why it hasn't gotten a larger audience. :unsure:

 

Now about AI: I see Springheel's post above me at the time of writing and he's very much right. It's the processing of the AI that zaps the power, not the model.

Share this post


Link to post
Share on other sites

Yes, I would love to see what people could squeeze from an outdoor scene in TDM using all the tools and tricks available. :)

 

The shame of it is that it's not all the engine's fault per se. Doom 3 leaves much of the renderer optimization to the mapper.

If Dmap were better or included more features for light carving, merging lights, auto-generating light projection images (etc)

in ways that the human mind is hard pressed to understand, we could possibly have much more performance too. We don't

even know the full potential of the vanilla Doom 3 engine or TDM engine because we generally cannot build the way the

engine would prefer and the automated optimization tools are rudimentary.

 

As for Portal Engines being poor at outdoor scenes?

 

I may sound like a broken record but I've come to think of the Portal as another LOD context. This would be especially effective

if we had some sort of render-to-texture\billboard system for portal skies. (Or even just having 7318's portal sky fix ;) ).

 

Without such fixes, mappers could still place self generated textures from in-game screen-shots on func_portal patches

that would mask the transition better and a little fog would even cover any visual anomalies from closer views of that.

 

Decorative ambient lights can be scripted to turn off at distance to the player or via the location system for a little performance boost.

 

You can set objects to noShadow skins via LOD but the last I heard disabling the shadows of the actual light isn't possible? (tracker 563)

 

I know you can script shadow removal from lights by changing their shader

 

$<mylight>.setShader ("lights/<example_light_shader");

 

Can you get the LOD state from a script? I think you can use the $<entity>.getKey to poll an entity for it's LOD skin?

 

If not you'd need to do a distance check in script or via location system.

 

Eg do a conditional on:

 

distance = $player1.distanceTo($<example_light>);

 

 

Edit:

 

updated tracker 563 for further feedback...

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

Without such fixes, mappers could still place self generated textures from in-game screen-shots on func_portal patches

that would mask the transition better and a little fog would even cover any visual anomalies from closer views of that.

 

I wonder if this could be automatized with skybox camera kind of trick:

There is a visportal, which is also a camera. The camera takes a shot of the contents of the other side and applies the scene to the other side face as a texture. That way the portal could be closed, but the contents of the other side would be present on the face of the closed visportal. As an image, so scene of any complexity would be only 2 tris.

  • Like 1

Clipper

-The mapper's best friend.

Share this post


Link to post
Share on other sites

There is a "noshadows_lod_x" spawnarg where x is the lod distance the object is at. As the spawnarg "noshadows" is used on both objects and lights, I guess this could be handled by that.


FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

I wonder if this could be automatized with skybox camera kind of trick:

There is a visportal, which is also a camera. The camera takes a shot of the contents of the other side and applies the scene to the other side face as a texture. That way the portal could be closed, but the contents of the other side would be present on the face of the closed visportal. As an image, so scene of any complexity would be only 2 tris.

I'm not sure this would work. The problem is that for the camera image the image itself still needs to be evaluated. So I guess this would increase the performance impact instead of decreasing it.

 

EDIT: I think that, as the idtech4 engine is originally designed for indoor areas, it's a bit cumbersome to get good looking and performing results for other hings. Other engines are designed for outdoor purposes, and if one want's to create a game with such, they better stick to them. On the other hand, if someone want's to create high-detailed indoor areas with realtime shadow-casting lights, the TDM engine would be preferable. I fairly doubt that for example the engine used for Skyrim would reach that in the same way.


FM's: Builder Roads, Old Habits, Old Habits Rebuild

WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Share this post


Link to post
Share on other sites

There is a "noshadows_lod_x" spawnarg where x is the lod distance the object is at. As the spawnarg "noshadows" is used on both objects and lights, I guess this could be handled by that.

 

No, this will only prevent the light entity (model or brushes) itself from casting shadows. This will not prevent the light volume from calculating and drawing shadows.

 

Though, in a roundabout way, this accomplishes mostly the same thing... you could just apply this to all pertinent geometry and no shadows would be drawn for distant

objects. The questions being: "how expensive is it to evaluate the volume for potential shadow casters? does the engine do a good job of killing the shadow casting branch

early once it's done that evaluation? how much could you save if the engine knew never to calc shadows for a distant lights?"


Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

I wonder if this could be automatized with skybox camera kind of trick:

There is a visportal, which is also a camera. The camera takes a shot of the contents of the other side and applies the scene to the other side face as a texture. That way the portal could be closed, but the contents of the other side would be present on the face of the closed visportal. As an image, so scene of any complexity would be only 2 tris.

 

I believe that "camshot" can accomplish this:

 

http://www.doom3world.org/phpbb2/viewtopic.php?f=1&t=10210

 

http://www.doom3world.org/phpbb2/viewtopic.php?f=56&t=9045

 

 

The problem is that it works via Objectives logic...?


Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Share this post


Link to post
Share on other sites

So I was reading one of those "vs" articles between Doom3, HL2, Farcry, etc. It seems that at the time (maybe even today), Doom3 impressed all with the dynamic lights mechanics, but fell short in most of other factors of compelling gameplay. The engine seems to be plagued by the game's design choices, of persistent pitchblack darkness and hallway gameplay, that bans complex outside areas completely. Someone posted an article that says adoption of the engine after it going open-source has been pretty low (http://www.phoronix....item&px=MTIzMjU). Since Im a total illiterate in terms of gaming technology, and thinking about all the available "free" engines (some more than others) that are available today, like Unreal's, Unity, etc, I was wondering what would be the point of using IDTech 4 today? Or saying it in another way, what would be the type of game or situation where you guys, that know about this (GameDevGoro, Serpentine, etc) or simply like to follow these things, would see as the perfect reason to use Doom's engine instead of another? Is it really a modern engine you could base your indie game entirely upon nowadays? For what kinds of games?

 

Let me tell you what other haven't told you (or maybe they did, but I am too lazy today to read over whole thread, sorry :P)

 

The only downside of using GPL engine is that you won't be able to port your game directly to consoles, or Win8 App Store (or any app store that doesn't allow GPL apps). In case of idTech4, you can port your game directly if Bethesda will like your game and will be willing to publish it. Then you can almost drag and drop game code into Doom 3 BFG engine (assuming it's your code and not code of one of the existing mods for Doom 3). So in case of idTech 4, from business perspective, there are no downsides.

 

From technology perspective, it all depends what is your game is about. You can make Doom 3 remake, accepting limitations of that kind of game, with stock idTech 4. Nothing, absolutely nothing, prevents anyone from make Doom 3-like game with improved gameplay. Original game sold pretty well and is still selling. So if you make it right, you have a good chance of making worthy game. Not to mention that you don't have to code anything extra in C++ (you would have to recode DoomScript stuff).

 

Ask yourself, what is modern engine? Is it an engine that allows you to press a button "make a game" and your awesome game will magically appear? No, not at all. Modern engines simply utilize modern programming methods, they are more or less optimized for modern and future hardware. That's about it. Since idTech 4 is open-source, it means you can find a programmer which can implement certain features to modernize idTech 4. Or better get Doom 3 BFG, make it moddable and most of your "idTech 4 is not modern" issues will disappear.

 

Even stock (ok, not entirely stock, but slightly modified) idTech 4 can handle pretty large outdoors. Those outdoor areas are not too large to be suitable for long vehicular trips, but for on-foot / slow kind of vehicle action those outdoors are damn large. What makes me say that? That's because I tried it and it works.

 

Let me put it this way - it's more about art assets and gameplay to a good game than what engine it uses. Any engine requires manual optimization of level. There is no magic buttons to do work for you. Some engines are slightly better at it than others, but you still need to be careful of what you do.

 

If you are going to work alone, absolutely alone (no one to share future profits with) and you don't care for Mac/Linux, go with UDK. Even with their royalty share, you will be well off. Don't go with Unity, because unlike UDK / idTech 4, Unity doesn't come with game code. And most of the code snippets available are not high quality smart and optimized code. Unity is good for mobile platforms if you know how to code solid game code.

 

As for low adoption rate, it is simply because UDK / Unity is used in every studio around the world. Most people want to work at some established studios instead of going on their own. So why a person who wants to go in that career direction will deal with idTEch 4 when no one in the industry uses it? That's the only reason for low adoption rate.

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...