Doom3world

in vanilla doom3 AI had problems when walking over entities (like the monsters could walk over trap doors) if big chunks of the map are entities (models instead of brushes) how is going to change this for the AI? can the AI be overhauled so it can walk over models? because first modeling the world and then covering the world with unrendered brushes can be an arduous task.

IF AI pathing were to get an overhaul to deal with the entity issue id love to see navmesh support added to the game

it would be a better fit for a modern mesh based environment authoring workflow anyway

-edit

found this nice write up on the advantages of nav mesh over waypoints
http://www.ai-blog.net/archives/000152.html

There is an open-source/commercial license compatible navmesh library called recast that seems to be relatively mature. Once again, I'm unsure just how simple integrating this library into the code base would be. It could take a fair amount of work for all I know. As far as I understand it, navmeshes are not quite as robust as waypoints at the moment since recast doesn't support any 3d navigation for flying or swimming entities. Recast is continuing to make advances in that regard, but I think there are still some problems that are being pondered. I'm not completely sure how AAS works, so it's limitations are unknown to me, but it may not have outlived its usefulness yet.

i am sorry i do not mean to come off argumentative but i must disagree with this statement

navmeshes work very well with flying vehicles and water and using a height map can even be used to limit a vehicles z-stall (the height a vehicle can fly before it stalls to avoid infinite height which obviously wouldn't work in a game) for examples of this see the nav mesh implementation in unreal engine/UDK

it would be far fairer and more accurate to say that recast isn't as robust as other nav mesh implementations which themselves are far more robust then waypoints

not that this is a terrible thing

epic and others using closed solutions can surely sick as many people as they can hire on making these things work well while recast being open source project simply doesn't have the same manpower and/or $$$ attending to the problem

however with that said the fact that better implementations are out there and being used today should only show that it IS possible with recast too

its just a matter of digging in to that code and setting it up (i know I'm making that sound easier said then done but surely somebody must be able to solve a problem that has already been shown solvable by others)

on the subject at hand how would the VT apply to dynamic objects (breakable/movable crates etc) replaceable items (health pickups etc) and characters (including the first person arm/weapon model)

The aas is fine and is quite advanced. It's not a simple waypoint solution as it provides full 3D information about the environment to the AI as well as handling dynamic obstacle avoidance. It doesn't need to be replaced, maybe just improved upon, mainly with regards to performance.

There's some good info here on Doom 3's AAS and if you want to really dig into id's AI/AAS, here's van Waveren's site that has links to his thesis/publications on the subject.

One of our lead developers at The Dark Mod, Grayman, already enhanced AAS pathfinding to better handle Func_Statics. I believe the
opportunity to improve AAS has been there all along in the "Game SDK" but not many modders have ventured to try and
augment or replace it's features. Other than the lack of skill to accomplish such changes, the reason we probably haven't seen much work
on AAS is that the Collision code was not in the SDK and that would make any drastic changes to AAS hard to debug (but not impossible).

It's much the same story for the "open source physics SDK" in the Game code. Sure, you can rewire all aspects of Physics processing in Doom 3
but if your changes don't work as expected due to bugs or unexpected features in the Collision code you are going to be doing a lot of
trial and error.

Let's not speak about the Trial and Error for writing ARB shaders and how hardware vendors do "stuff" to ARB code...
Maybe the shader programmers have stronger stomachs than AAS or Physics coders?

Don't worry, I didn't take it as argumentative as all. I'm still learning about all this stuff, so I know I'm going to say something completely inaccurate at some point, and I found your counter-argument to be quite informative.



Thanks for the links. I've seen the one on modwiki before, though I haven't gone through it thoroughly yet, but the other one is new to me.



Actually, I was wondering lately if jmarshall23 had any plans for modifications to the physics code. Though, I would say that enhancing the tool base would probably be more useful at the moment.

Not quite at the same level as virtual texturing, but here's some shots of a simple blend shader (up to 4 materials, single pass) :

That is awesome!

That is awesome. How does it handle white? I assume it's an even mixture of three?

To keep things simple in the shader and with creating the mask, I'm doing the blending in layers. Texture4 is like the base layer, then texture3 is blended based on what's in the blue channel of the mask, texture2 is then blended based on the green channel, and then texture1 based on the red. This goes for normal, diffuse and spec. I could use the alpha and blend 5 textures but 4 is good enough for now. The mask texture's scale is also customizable as well as scale & biasing the channels to harden/soften the blends.

A couple more shots that show this off a little better (last post on this, jmarshall23, promise)

could this be combined with the vt or would the two features be incompatible?

VT negates the need to do that sort of thing, but blended tilemaps might be a good tool for creating the base VT. id used something like this in the early idStudio terrain generation: http://www.youtube.com/watch?v=dbgZJPVb ... r_embedded

yeah i figured as much i guess the better word to us would have been redundant over incompatible

bummer though we have to great codesmiths working on great features i wish there was room for them all in one engine

as far as this engine goes i have a bit of a wish list of things id like to see in the in engine texture tools

do you by chance intend to add or have you considered adding photoshop psd support layers and brushes?

it would be great if the tools supported photoshop format brushes since so many of us artists already have such an extensive collection built up not to mention the billions available online

would this be something we could look forward to?

and if psd support was added how about live updating ie i change something in photoshop it gets bounced straight to the engine tools

Hey sorry its been a bit if you've checked the SVN just wanted to give a few updates:

NEW FEATURES:
x64 support(x86 will no longer be supported).
16384x16384 VT's(tiles still show up blurry for some reason, dxt compression)?
Added geometry shader support.
Moved VT stuff from deferred renderer to its own shader.
Added GLSL pass support.



Why? Your not hi-jacking the thread , honestelly keeping everybody up to speed on what everyones doing is a great idea and honestestlly I don't really read any other threads besides this one.



Exactly, masks can only go so far; vt takes it the rest of the way. For mobile platforms, I might have to stick with blending layers tho.



Would you be willing to share this code? I completely agree that AAS is really one of the if not most advanced AI handling system out their compared to other solutions.



Physics was never my area, if I get some time in the future I will look into it(or when I can't do something in one of the demos), but if someone wants to see this done it would be faster for someone else to get this done as its not high on my priority list(since 80% of the time it gets the job done).



For dynamic meshes/2d stuff I plan on adding support for layered textures. All textures I plan on automatically converting to a custom format each time there source files change from the source directory(and would get put in a "generated" folder).

does this mean the engine will not run on 32 bit machines or machines with 32 bit OS's?

Yeah, though I'm 64bit, it seems like a terrible idea to cut support for 32bit if that means they can't play.

knocks me out as i am running 32 bit windows 7

agreed terrible idea

(no offence)

Damn I didn't realize there were still that many people on x86, the code still compiles properly against x86(everything is properly macroed out). I'll support both but the toolset will pretty soon require a x64 CPU(as is you need atleast 8gb of ram to build a VT in mudbox).

This paticular test is x64 only(ill recompile later tonight for x86).
http://multiupload.biz/file/1YUMNWWN/test04.rar

http://www.youtube.com/watch?v=welulLI1 ... ature=plcp

Right now it does require 16 4096 textures on the hardware and syncing issues kinda of cause FPS problems both ill rectify tonight(I know exactly what i need to do ).

I'll support both x86 and x64 for clients, but as I said you have to have greater than 4gb of ram to build a VT.

Steam Hardware Survey has 64-bit OS adoption at 60%, so you're dropping 40% of users by doing that.

There isn't any obvious gain by dropping 32-bit support, just make a separate configuration for it if you want an x64 build.

If you need >4GB of RAM for a VT build then just disable builds on x86, although I think you should just look in to disk caching instead, i.e. build it in chunks and then reassemble the chunks in a separate pass, which is incidentally better for distribution and multiprocessor carve-outs.