Doom3world

The project is now maintained here:

http://blackenmace.com/

The SVN link has changed! For the current up-todate link and information please visit the site above.

Ok, soooo looking at this post, a few things sprang to mind. The first is that your screenshots are showing off nothing. Its one thing to show art when you can't do it, and thats perfectly fine, not everybody is a full time dev work force... but the pics were so small, I can't see anything. Even on the level editor shot, I can't read anything.

So, lets get down to it.

POM - How is it done? Why in the alpha? I know its cheaper, but that means you can't have alpha masking on POM surfaces. How many stagse does this add to the material and whats the overdraw like? What are your parms set up like in the material? Scale, steps, min distance & max distance I presume?

Defered Shading - I can't see anything or tell anything. At all. The screenshots terrible.

Post Processing "Stuff" - Is called a lot of things, LUT, colour grading etc. But whats the interface like? Is it set up per area I imagine? Whats the cross fade between volumes? How many options are there? Standard options I would expect are Bloom contrast, bloom threshold, base intensity, glow intensity, RGB control of shadows, RGB control of highlights, RGB control of midtones, RGB min output, RGB max output, RGB control over saturation levels, RGB control over the tint, and control for loading external .LUT look up files for colour grading. Bog standard stuff there.

Editor - Some of those editor changes are... Stupid. Why remove .lwo/.ase etc support, when those are perfectly fine examples of model formats to work with inside the editor? Just a total step backwards...

GUIs - You know why they made the GUI that resolution, don't you? Theres NOTHING stopping anybody from making a GUI with uber resolution that looks pixel sharp on 1080p sets. Not a thing. The reason they made it 640x480 is that its devisable easily, but more importantly its a minimum resolution for the game to look acceptable at. This means that dropping to 640x480 will still render everything correctly on the GUI side. You increased it to 1280x720, which is a totally strange choice because it now means you need to be in 720p quality or else the HUD, GUI and everything else 2d will fuck up. That cuts a HUGE number of players out who run not only in sub HD resolutions for speed, but also 16:10, 4:3 and 5:4 etc etc resolutions. You should have stuck with 640x480, and just created wide screen scalable GUI's that can be positioned based on aspect ratio and user need.

I dunno about this moving towards something that people would use thing is even right. The problem with the Doom 3 code isn't that its lacking, its that its messy. People can add stuff as they wish, but at the moment you seem to be adding useless half done features, and removing things at will because it won't fit your project needs, but then saying its something for people to use instead of the actual Doom 3 code base? That doesn't make sense to me, and seems a tad counter productive.

Did your removal of ASE and LWO support have anything to do with the issues relating getting models to work that are exported from blender?

Because I can't really see why you would use the FBX format other than it recently got added to blender for UDK users who complained about ASE exporters. Adding the support for FBX was a step kinda in the right direction but still don''t know why you removed the other 2 formats.
On another note I must agree with gavavva about the SCREENSHOTS. I can't see anything. It looks like RAGE with broken ATI drivers. So maybe if you could include some high resolution screenshots. Also GUI changing is not the best of ideas as the 640x480 GUI seems to be more of a GRID reference than anything else. Like what was said by gavavva(again) you can get awesome looking GUIs that look full HD from the 640x480 GRID from doom 3.

Ok just on another note I am not a coder. I burst into flames when confronted with code. But I believe that most of the feature in SIKKMOD is what id tech 4 needs to become standard. What I would like to see in id tech 4 are the following.

Soft Shadows
Motion blur or bloom effect
Parralax Occulusion Bump Mapping (which you are busy with)
Multi-core support (suggested this to a friend that has years of coding experience he couldn't stop laughing for a week so I know it would be difficult but I do believe id tech 4 would benefit from it)
I also want Larger Megatexture support equivalent at least to Quake Wars.(With compression)

So will FBX basically become the modeling standard for your WORLDSTUDIO? With animated FBX models becoming the MD5 equivalent? That might be good not to sure yet. It will just be easier to get models from blender to id tech 4.

Just so you know I do want to help and I am currently using id tech 4 to create a "little" tech demo for a project I've been working on for about a month now. A simple description would be Halo meets fallout but that's just art wise. I can't really do much with code. So while everything might look nice it will play like BIG RIGS OVER THE ROAD RACING

Jesus Christ, feels like he took your money to work on this mod. Chill out man.

I agree, screenshots are not that good, but why so serious? And about the FBX thing, I think you never had the chance to work in a pipeline that supports FBX, cause the day you have to you'll start to piss on .ase .lwo and other formats that are just... old.

It's a fad. The format to save a model doesn't mean a thing except for filesize, it's the modelling software that counts.
There is no reason to take out .lwo and .ase as they are widely supported and used formats. If the goal is to make a public base then taking out support for any format means cutting away from the user base. I for one would not look forward to converting all my static meshes to a different format, if I'd be choosing one of these base code packs for my game.

As for your other comments, jmarshal came here looking for (I hope) honest feedback. There are other forums to go to if he was searching for cheers and parades, here there are mostly hard working modders with a lot of experience in these matters, the truth might not always be nice, but it's what you'll find here.

Ahaha you really don't know what you are talking about. Who cares about filesize, it's about how easily you can save and import assets in a game engine. Keep your beloved formats, like ase, edit them in notepad... And let professionals use fbx, one click save solution found in every major 3d app that gives you a game engine ready model including animations, camera sequences, lights, etc. While an artist is importing large assets easily in UDK, you are probably trying to compile a working dll to link Maya with doom3 engine to save md5 files, or, you can use the dll Id shipped with the sdk... If you are still using Maya 6.0. And still, you have to write thousands of lines in def files... If you prefer to spend your time in front of notepad, do it, just don't piss on others who are looking for a more easy solution Jesus Christ, guys, we are in 2012, use technology to your advantage.

LWO and ASE formats are widely supported in most apps, BUT SO FBX, and everybody is rushing to implement that BECAUSE of the potential it has. Even Blender supports it, cause (as others said) working with .ase files were a pain. It's becoming the most universal format in the 3D world, you can just send a maya model to a 3D Max guy, or a Blender guy, and it will import without 1 problem, still featuring materials, uv's, animations, blendshapes, camera animations, light positions...

As for my point, I will say "There's a difference between being Frank, and be a Dick" (cit.) so the mod has potential, and yea: art stuff it's too raw to get an idea, screenshots are too small, so just point that out, without being rude. That's all, nothing major, what do you think?

Ps: probably slush_puppy's intent was not to be as rude as I am pointing out, but the guy is implementing lots of really big improvements to the engine, we should encourage him, and not insult him because he posted small screenshots

I've seen nobody insult anyone, except for you.

May I ask you to point out the sentence which contains the insults? Probably I've chosen a bad word, I should have chosen "aggressive".

Sorry if anyone feels I insulted them. As I stated my knowledge of coding is that of a wet sponge. I just voiced my opinion of what I would like to see. I am excited about his attempt at creating something fresh from id tech 4. I was just wondering why he went with FBX but as some modders use open source software(like myself) I can see the benefit from using FBX as it is officially supported by blender for UDK so if you make a model for UDK you can use it in this id tech 4 revision.

I just want to see some features that are in SIKKMOD become standard in this engine. But that is my opinion. I really am interested in helping this guy and believe he has done some amazing work. I have not really seen any id tech 4 projects that has attempted anything like this yet. Most projects are just about cleaning up the code. While this is beneficial. To the average NON CODING JOE like me that if we can't see it it doesn't exist it means nothing really... I wanted to see something done with tech 4 and here it is. I would just like to see better screenshots of the graphics or even get a compiled demo that he is currently running so I can see it myself on my PC.

So brilliant work jmarshall23 please drop me a PM or email I am really interested in helping.

Yea as I said I used "insult" a bit too easily (but I'm not the only one, as it seems) so I'm sorry for that, but at the end I'm becoming every day more nervous about how this comunity is trying to stick to 1998 without looking for the future. Brand new editing tools, improved workflows featuring this generation assets management system, features like deferred shading are incredible features that will not only make the Doom3 engine LOOK better, but will, hopefully, attract lots of modders that wouldn't touch doom3 engine "as is" because, let's be honest, why in the hell I would use and engine like Idtech4 when there are lot's of engines available for free, that features way better, easy to use tools.

I'm amazed how BloodRayne can miss such a point, and prefer the "I code my websites in notepad, so I'm happy as it is" way. It's a good thing when you have no options, so you can still produce even in a unfrendly environment, but in 2012 there are LOTS of better options, so why stick your head in 1998?

EDIT: last thing, I promise; I'm not the one who labeled the OP work a "fad", so...

arghh! NERDRAGE!

I'm not one to be willingly blunted on the end of your dumb assumption stick, thank you. Stop referring to me in your posts; and MUCH worse putting words and opinions in my mouth that I've never said or held.

- I didn't miss any such point.
- I didn't call the OP's work a FAD. I called FBX a fad, learn how to read.
- I never said you should work with outdated tools. I didn't even speak about tools per se. I was speaking about fileformats and how one file format is not more beneficial than another unless they are smaller in filesize. Ultimately it's the TOOLS that matter and the artist that wields them, do you know the difference between all of those? How would FBX be a 'better' format. Do the models suddenly look magically better because they are saved in FBX?

And then you go on to say that 'filesize means nothing'. And you say that to a person that has released 4 big projects for the IDTech4 engine, a person with over 15 years modding- and 20 years of programming and business experience. What are you on? Crack? Filesize means nothing? Say that to the Steam platform and the guys hosting the servers that need to release the work. Every byte is important. And the only thing that can make any model format superior is small filesize. So why was FBX better than .ase and .lwo again?

First off excelent critiques! BloodRayne had some excellent points, please don't deter anyone from speaking their mind .



Programmer Art .



Right now thats based on the alpha channel in the material, but you just brought up that I should have these setup on a per-material basis. I put in alpha of the diffusemap as a hack nasty diffenetly will move into the normalmap(I wanted to save a texture unit there is no reason to have the heightmap as its own texture).


Completely agreed this wasn't ment for artists to look at : ), programmer art FTW .



FBX is industry standard as other people have said there is no reason to support the other formats, basically just felt like deprecated code.



I haven't met a person in years that didn't have a 1080p monitor and odds are anyone atleast playing my game won't be the casual gamer(i.e. Mommy ). so for me its a non issue : ). 640x480 GUIS look nasty and right now in a lot of places in the engine it was hardcoded so that could be the highest res guis possible, I just simply upped it to a widescreen ratio; In my opinion looks better.



Its moving the codebase to match where the industry is going, which does mean cleaning up the code(and removing deprecated features, and file formats). The editors are nasty and clustered. What I also plan on doing is having per-material GPU shaders(like in Unreal), which would open up the engine for a node based material editor. Its all about streamling the toolset to make it more productive.



No FBX will just be what the engine IMPORTS to convert to MD5(opens up a bunch of other modeling packages besides Maya).



Basically the removal of ASE/LWO came from the fact compared to Unreal or Unity its a pain in the ass to get assets into idTech4, and I just figured that artists know how to export to FBX, which would make the toolset that much more appealing to them. Basically there isn't FBX support in the model loader, all FBX is for CONVERTING to either a skeletal MD5 or a static mesh MD5(NEW format that gets generated from a FBX). The FBX support is only in the toolset, the fbx sdk alone adds like 10megs to the final binary :/.

What I really is a artist to help dev assets, my screenshots depict programmer art which doesn't fully demonstrate what the code is capable of doing.

Yeah that's right... Still, to me translate to "you are loosing your time, dude, time spent on FBX is not gonna worth". But yea, could be my fault, I admit (being serious)



And you want to let me believe that you are not missing a point? Again, may you kindly point to me where I said "models saved in FBX looks better?" Please, do! But... You can't find that sentence anywhere because the whole point *you are missing* is about FORMAT IMPLEMENTATION, NOT THE FORMAT PER SE. That's the point you are missing, and it's crystal clear after what you have just written. Artists don't give a fuck on how FBX or ASE are coded, which would look better in Ms VSStudio, how they formatted the code etc... They CARE about the fact that (read carefully, please, because I wrote this 2 times in previous posts, but seems like you skipped it) you have a UNIVERSAL file format that not only can be opened in all 3D packages WITHOUT any assle, but (if your game engine supports it) gives you ONE CLICK import workflow for (again) animations, models, cameras, props etc. It will not look BETTER, It's just way easier and user friendly to work with.



I know really well about your work, and, If you noticed, I haven't said "You know shit about modding". I never thought about something like that, but if you fail to see how much easier is to work in a open environment where everybody can import an animation with one button click, either you haven't had the opportunity to work in such environment, or you don't care about improving your pipeline in both speed and "userfriendliness" (sorry for the word : D )

Can you please tell me why EVERY, (it's not "most", but EVERY) current gen engine supports Fbx, direct Psd file formats etc? Unity, UDK, CryEngine3 and I bet (a beer?) Idstudio they all support such things. Why if "format doesn't make any difference"? Because, AGAIN AND FOR THE LAST TIME, it's not the format itself, it's how is tied with the applications it has to serve (3d apps and game engines). So, yes, doesn't matter what you say, or the fact that you have lot's of mods in your portfolio, FBX is a better file format not "per se", but because of how it is supported by industry standards.

About filesize.. lol I can't believe you prefer to release a game after working on it for years using 10 years old tools, just to save 200 mb. We are in 2012, look around you, people would download a 5 gigs mod like GtaIV hi res texture pack without thinking twice... People will even download Rage, that is HUGE, just because they won't pay for it. So no, sorry, a thousand of Mb won't really be noticed.

Anyway, I'll try to relax a bit, I was very aggressive and I can see how my posts should have a much more coolness approach.

Umm ok, so:

Rather than flamming the foliage... Is anyone going to use a different art design in Doom 3 projects? I am starting to be bored of the dull and brown style out there.

I mean, srly...

There is a huge need of texture memory and there is no streammmmmming...

http://neosurrealismart.com/3d-artist-g ... astleM.jpg
http://3.bp.blogspot.com/-7jF9uXJOYMU/T ... ontier.jpg
http://www.hormiga.org/fondosescritorio ... -Libya.jpg
http://www.mountainphotographer.com/wp- ... owPeak.jpg
http://cache2.allpostersimages.com/p/LR ... r-cave.jpg
http://www.travelerswonder.com/wp-conte ... Park-4.jpg
http://static1.cornucopia3d.net/galleri ... 20city.jpg
http://static.desktopnexus.com/thumbnai ... mbnail.jpg
http://images2.layoutsparks.com/1/20946 ... forest.png
http://www.wallpapergate.com/data/media ... no_002.jpg
http://fc06.deviantart.net/fs34/i/2008/ ... rtenyo.jpg
http://www.evcal.org/sitebuilder/images ... 25x328.jpg
http://agaudi.files.wordpress.com/2008/ ... _a_03c.jpg
http://bitewallpapers.com/space/space%2 ... saver.jpeg

What I was playing around with in my head was implementing either PTEX support or Virtual Texturing support using the same concept that Rage did( baking everything into a large ass texture that gets streamed in as needed). The current problem with that is, the only standalone solution that would be sutiable to build each tile is Autodesk Beast(expensive ). What I could do is during level build, export the world out into maya/3ds max and use either to render out each surface into a large texture paging file. The problem is I don't want to have it be a required to own either of those two packages to build a game. Does anyone have a better solution?

Upgraded physics and multicore support for both CPU/GPU are a must. (OpenCL/OpenMP cap.)
Encryption system for pk4 files in order to don't steal code/assets without releasing the sources by the autor.

As I said in pm, I could offer some 3D work. Let me know if you need

@=FF=Sturm: Yea, I can see your point, what Idtech4 needs is something that starts to take advantage of Sikkmod (soft shadows, cubemaps lights, sun shafts etc). In the past doing such organic enviroments using only stencil shadows, no serious ambient lighting, great post processing was just impossible, but now things would be better. Deferred shading it's what really needed to make believable and cool lighting. If it was for me, I'd probably go for a good lighting engine, and leave megatextures as last thing to implement!

Encrypting the pk4 files is good idea but any type of zip encryption can easily be reverse engineered(especially on a open source project), I plan on leaving that up to the individual teams/studios so they can come up with a tailed solution to meet their needs.

Correct me if I'm wrong, but I haven't really seen that multicore hardware rendering really helps anything. The only thing it would help with is with virtual texturing support(so hard drive reads aren't slowing anything down), and with smaller stuff like loading animations. The biggest bottleneck in rendering is the BUS, all multicore support would do is allow for simaltanous uploading of scene content but it wouldn't go that much faster cause of the BUS.



I'll check that right now : ).

Multicore support helps in Unreal engine 3. I had a radeon 1950xt and tested multiple times on different CPUs. The end of the day a Intel q9300 2.5ghz cpu outperformed a Intel E8400 overclocked to 3.5ghz...On the E8400 1920x1080 would run at about 45 - 60fps on the q9300 ran 65 - 85 fps.Also would help with compile times for maps in UDK. (not that tech 4 compiles very long)
Not really sure how it would work in tech 4. I know quake 4 got multicore support later but it was bad. Gave me something like a 5% increase in performance.

UDK bakes all non dynamic lights, so for generating radioisty normal maps/lightmaps multi-core processing is a must have. Thats interesting that multi-core support in UDK gave you better in game performance. In idtech everything is in VBO/IBO, which essientially means aside from skeletal animations everything is already on the graphics card, so aside from state changes I don't know how much of a performance boost idtech would gain from multi-core support. UDK from what I understood, didn't really make use of constant VBO's/IBO's but rather blitted all the vertex data directly to a dynamic VBO/IBO, this might have changed, but that would account for your performance boost with multicore support.

Anything more heavy duty I plan on moving to either OpenCL or Cuda, but VT will obviously have to have multi-core support.