jmarshall23@Posted: Sat Mar 10, 2012 5:22 am :
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.



gavavva@Posted: Sat Mar 10, 2012 12:06 pm :
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.



slush_puppy@Posted: Sat Mar 10, 2012 2:22 pm :
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



Dolce Decadenza@Posted: Sat Mar 10, 2012 3:36 pm :
gavavva wrote:
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.


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.



BloodRayne@Posted: Sat Mar 10, 2012 3:43 pm :
Dolce Decadenza wrote:
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.



Dolce Decadenza@Posted: Sat Mar 10, 2012 3:56 pm :
BloodRayne wrote:
Dolce Decadenza wrote:
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



BloodRayne@Posted: Sat Mar 10, 2012 4:43 pm :
Dolce Decadenza wrote:
and not insult him because he posted small screenshots

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



Dolce Decadenza@Posted: Sat Mar 10, 2012 5:04 pm :
BloodRayne wrote:
Dolce Decadenza wrote:
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".



slush_puppy@Posted: Sat Mar 10, 2012 5:04 pm :
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.



Dolce Decadenza@Posted: Sat Mar 10, 2012 5:38 pm :
slush_puppy wrote:
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...



BloodRayne@Posted: Sat Mar 10, 2012 6:31 pm :
Dolce Decadenza wrote:
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..

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?



jmarshall23@Posted: Sat Mar 10, 2012 7:36 pm :
First off excelent critiques! BloodRayne had some excellent points, please don't deter anyone from speaking their mind :).

Quote:
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.


Programmer Art :).

Quote:

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?



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).
Quote:
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.


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

Quote:
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...


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

Quote:
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 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.

Quote:
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.


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.

Quote:
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.


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

Quote:
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?


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.



Dolce Decadenza@Posted: Sat Mar 10, 2012 7:41 pm :
BloodRayne wrote:
Dolce Decadenza wrote:
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..

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.


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)

Quote:
- 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 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.

Quote:
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?


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.



=FF=Sturm@Posted: Sat Mar 10, 2012 7:43 pm :
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

Image



jmarshall23@Posted: Sat Mar 10, 2012 7:56 pm :
=FF=Sturm wrote:
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...


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 :P). 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?



=FF=Sturm@Posted: Sat Mar 10, 2012 7:59 pm :
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.



Dolce Decadenza@Posted: Sat Mar 10, 2012 8:06 pm :
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!



jmarshall23@Posted: Sat Mar 10, 2012 8:07 pm :
=FF=Sturm wrote:
Upgraded physics and multicore support for both CPU/GPU are a must. (OpenCL cap.)
Encryption system for pk4 files in order to don't steal code/assets without releasing the sources by the autor.


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.

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


I'll check that right now : ).



slush_puppy@Posted: Sat Mar 10, 2012 8:48 pm :
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.



jmarshall23@Posted: Sat Mar 10, 2012 9:07 pm :
slush_puppy wrote:
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.



jmarshall23@Posted: Sun Jun 03, 2012 11:58 pm :
New Stuff in SVN:

65kx65k VT Support(the final filesize hovers around 4gb).
New filesystem functions to load larger than 2gb files.
You can now select faces in the editor.
You can now mark surfaces as nodraw.
Added/Fixed the Q4 script debugger.



jmarshall23@Posted: Tue Jun 05, 2012 7:43 am :
Got up a quick screenshot of a indevelopment level using 65k vt's(clear your internet cache):

http://blackenmace.com/



jmarshall23@Posted: Fri Jun 15, 2012 12:30 am :
I've been working on in editor paint tools and I've mostly got it working but as you can see from the screenshot edges are currently a issue.

Attachment:
vtpainttools.png
vtpainttools.png [ 255.33 KB | Viewed 236 times ]


Currently I'm tracing a unprojected ray against the world to figure out a) what vt area we hit and b) that point needs to get converted back into 2d coords so we can figure out were to paint. To do the latter I'm using a heavily modified version of idRenderWorldLocal::GuiTrace. The problem is this function is very inacurate on non flat surfaces. My modified function below:

Code:
/*
================
VTTrace
================
*/
vtPoint_t idRenderWorldLocal::VTTrace( int vtAreaId, const idVec3 start, const idVec3 end ) const {
   srfTriangles_t   *tri;
   vtPoint_t pt;
   localTrace_t   local;
   const modelSurface_t *vtsurf = NULL;

   memset( &pt, 0, sizeof(vtPoint_t));

   if(vtAreaId == -1) {
      common->Warning("VTTrace: Can't trace against non vt areas.\n");
      return pt;
   }

   for(int i = 0; i < localModels.Num(); i++)
   {
      idRenderModel *model = localModels[i];

      //common->Printf("Generating Collision for %s - %d collision models\n", model->Name(), model->NumSurfaces() );
      for(int s = 0; s < model->NumSurfaces(); s++)
      {
         const modelSurface_t *surf = model->Surface( s );

         if(surf->geometry->vt_AreaID == vtAreaId) {
            vtsurf = surf;
            break;
         }
      }


      if(vtsurf != NULL)
         break;
   }

   if(vtsurf == NULL) {
      common->Warning("VTTrace: VTArea %d is invalid!\n", vtAreaId);
      return pt;
   }

   tri = vtsurf->geometry;

   local = R_LocalTrace( start, end, 0.0f, tri );
   if ( local.fraction < 1.0 ) {
      idVec3            origin, axis[3];
      idVec3            cursor;
      float            axisLen[2];

      R_SurfaceToTextureAxis( tri, origin, axis, &local.indexes[0], &local.plane );
      cursor = local.point - origin;

      

      int closestIndex = 0;
      if(local.d[0] > local.d[1] && local.d[0] > local.d[2])
      {
         closestIndex = local.indexes[0];
      }
      else if(local.d[1] > local.d[0] && local.d[1] > local.d[2])
      {
         closestIndex = local.indexes[1];
      }
      else if(local.d[2] > local.d[1] && local.d[2] > local.d[0])
      {
         closestIndex = local.indexes[2];
      }

      cursor = local.point - tri->verts[closestIndex].xyz;
      axisLen[0] = axis[0].Length();
      axisLen[1] = axis[1].Length();

      pt.x = ( cursor * axis[0] ) / ( axisLen[0] * axisLen[0] );
      pt.y = ( cursor * axis[1] ) / ( axisLen[1] * axisLen[1] );
      pt.x += tri->verts[closestIndex].st.x;
      pt.y += tri->verts[closestIndex].st.y;
      return pt;
   }

   common->Warning("VTTrace Failed.\n");
   return pt;
}


Basically what makes this function more accurate is I interporlate the position from the nearest point that got hit and extrapolate the final position that way. And it works 90% of the time but its still not as acurate as I need it to be. Has anyone been working on something like this that can provide some insite on what I'm doing wrong?



jmarshall23@Posted: Sat Jun 16, 2012 9:29 am :
Fixed a lot of the bugs with the VTPaintTool still isn't exactly right but got a lot more stuff in including layers, and the BSP compiler(DMap) will build the virtual texture from the MegaProject which means no more MudBox requirements :P. I'll try to release a editor build sometime with in the next week.

http://blackenmace.com/phpBB3/download/file.php?id=16



The_Raven@Posted: Fri Jun 29, 2012 6:52 pm :
Things seem to be quiet as of late since the last commit to the code.google repository was on June 16th with no activity since then. I'm not complaining since I'm fully aware that a lot has been accomplished recently and if jmarshall23 wants to take a bit of a break, then I think he's earned it. I was just wondering what the plan was going forward.

Also, I was looking at the video of the texture painting tool awhile ago and the only comment I can think of is that wouldn't the helper brush that shows where the texture is going to be painted work better if it was a decal that was projected on the terrain? Other than that, things look great so far.



jmarshall23@Posted: Sat Jun 30, 2012 12:59 am :
Quote:
Things seem to be quiet as of late since the last commit to the code.google repository was on June 16th with no activity since then. I'm not complaining since I'm fully aware that a lot has been accomplished recently and if jmarshall23 wants to take a bit of a break, then I think he's earned it. I was just wondering what the plan was going forward.

Also, I was looking at the video of the texture painting tool awhile ago and the only comment I can think of is that wouldn't the helper brush that shows where the texture is going to be painted work better if it was a decal that was projected on the terrain? Other than that, things look great so far.


That just means I haven't checked anything in : ), I'm moving everything over to a git repository I wanted to do a full release when I got most of the bugs fixed ill commit everything in a couple days.

That was just the initial implementation, the brush now properly gets projected on the mesh.



The_Raven@Posted: Sun Jul 01, 2012 9:00 pm :
That sounds great.

I'm probably thinking too far ahead, but what do you think you'll work on next after virtual textures get settled out?



The_Raven@Posted: Tue Jul 24, 2012 6:42 am :
I was just wondering what was currently going on with the project? The website has been down for a few days, so I thought I'd ask.



tea monster@Posted: Fri Jul 27, 2012 11:42 pm :
Same here.



parsonsbear@Posted: Sat Jul 28, 2012 8:04 am :
Haven't been any updates for a while. The last stuff seemed interesting- support for kinect!
http://code.google.com/p/idtech4cdk/source/list



Dashiva@Posted: Sun Jul 29, 2012 5:12 pm :
Yeah he looks like he has a history of stopping interesting projects if you look at the repository. Anyone up for forking it?



AnthonyJa@Posted: Mon Jul 30, 2012 3:29 pm :
It's a bit early for assumptions like that - it is the summer after all!



Dashiva@Posted: Wed Aug 15, 2012 6:05 pm :
I'd say it's pretty much dead at this point. He was going through 1 revision every day or so and then just stopped. I sent him an email asking if this was still going but no dice :/. Seemed like a really cool system.



anonreclaimer@Posted: Wed Aug 15, 2012 6:23 pm :
This project was improving the Doom 3 engine why would he stop.Well we can use his work so he didn't program for nothing.



Dashiva@Posted: Wed Aug 15, 2012 6:37 pm :
I'm not sure. Licensing issues? Anyway, the code is there for forking, someone just needs to take control and do something useful with it.



anonreclaimer@Posted: Wed Aug 15, 2012 8:42 pm :
I don't care about the licensing issues for now I got the source code from the svn and I'm going to make good use of it.



Dashiva@Posted: Thu Aug 16, 2012 5:14 pm :
anonreclaimer wrote:
I don't care about the licensing issues for now I got the source code from the svn and I'm going to make good use of it.


If you do start using it, is there any way you can set up an alternate repo with your changes? I still can't get it to compile, and I don't have the time to troubleshoot it.



jmarshall23@Posted: Sat Mar 10, 2012 5:22 am :
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.



gavavva@Posted: Sat Mar 10, 2012 12:06 pm :
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.



slush_puppy@Posted: Sat Mar 10, 2012 2:22 pm :
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



Dolce Decadenza@Posted: Sat Mar 10, 2012 3:36 pm :
gavavva wrote:
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.


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.



BloodRayne@Posted: Sat Mar 10, 2012 3:43 pm :
Dolce Decadenza wrote:
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.



Dolce Decadenza@Posted: Sat Mar 10, 2012 3:56 pm :
BloodRayne wrote:
Dolce Decadenza wrote:
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



BloodRayne@Posted: Sat Mar 10, 2012 4:43 pm :
Dolce Decadenza wrote:
and not insult him because he posted small screenshots

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



Dolce Decadenza@Posted: Sat Mar 10, 2012 5:04 pm :
BloodRayne wrote:
Dolce Decadenza wrote:
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".



slush_puppy@Posted: Sat Mar 10, 2012 5:04 pm :
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.



Dolce Decadenza@Posted: Sat Mar 10, 2012 5:38 pm :
slush_puppy wrote:
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...



BloodRayne@Posted: Sat Mar 10, 2012 6:31 pm :
Dolce Decadenza wrote:
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..

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?



jmarshall23@Posted: Sat Mar 10, 2012 7:36 pm :
First off excelent critiques! BloodRayne had some excellent points, please don't deter anyone from speaking their mind :).

Quote:
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.


Programmer Art :).

Quote:

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?



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).
Quote:
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.


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

Quote:
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...


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

Quote:
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 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.

Quote:
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.


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.

Quote:
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.


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

Quote:
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?


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.



Dolce Decadenza@Posted: Sat Mar 10, 2012 7:41 pm :
BloodRayne wrote:
Dolce Decadenza wrote:
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..

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.


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)

Quote:
- 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 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.

Quote:
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?


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.



=FF=Sturm@Posted: Sat Mar 10, 2012 7:43 pm :
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

Image



jmarshall23@Posted: Sat Mar 10, 2012 7:56 pm :
=FF=Sturm wrote:
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...


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 :P). 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?



=FF=Sturm@Posted: Sat Mar 10, 2012 7:59 pm :
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.



Dolce Decadenza@Posted: Sat Mar 10, 2012 8:06 pm :
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!



jmarshall23@Posted: Sat Mar 10, 2012 8:07 pm :
=FF=Sturm wrote:
Upgraded physics and multicore support for both CPU/GPU are a must. (OpenCL cap.)
Encryption system for pk4 files in order to don't steal code/assets without releasing the sources by the autor.


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.

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


I'll check that right now : ).



slush_puppy@Posted: Sat Mar 10, 2012 8:48 pm :
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.



jmarshall23@Posted: Sat Mar 10, 2012 9:07 pm :
slush_puppy wrote:
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.



jmarshall23@Posted: Mon May 07, 2012 6:36 am :
If you haven't been keeping up with the site/svn I've been fixing/optimizing everything from the VT UV Code to the editor to the renderer.

This is a terrain test im working on(to stress test to the code), the mesh is actually from the Megatexture V2 mod, just repainted up in mudbox(and gone through all the new VT optimization code). The normal maps look wierd cause im still autogenerating normal maps(but that nasty ass flicker is now gone, and the bumpmaps now render on all the surfaces correctly before it would only generate on the last one in view cause of blending issues).

Attachment:
autonormalterr.png
autonormalterr.png [ 416.16 KB | Viewed 221 times ]


You can view the full size screenshot at blackenmace.com.

Code:
FPS increase
Fixes to the VT uv code.
Fixed the "normal maps getting zeroed out issue" this was causing the errors in normal map generation and that nasty flicker(and hue problems).
Fixed a bug with some of the VT Backend textures not being created properly and causing nasty errors.
Scripts now work properly, all script types except for vector are assumed to be the size of a pointer.
Double click on a entity in the world entities tab will bring up properties(todo -- fixme -- this is wrong should be right click->properties).
UpdateEntities only option now works.
Fixed a problem where it would build indexes wrong and write tris numerous times to the world file(but not the obj).


Also got in a new command printimagestats, the difference between this command and listimages is this command queries all the image information from the hardware.



d0uble@Posted: Wed May 09, 2012 9:46 am :
:D

Image

download them:

http://blackenmace.com/phpBB3/viewtopic.php?f=4&t=20



jmarshall23@Posted: Wed May 09, 2012 9:02 pm :
Your images are live, ill repalce the admin avators later on today but the site looks way better with your logo :).



jmarshall23@Posted: Thu May 10, 2012 9:33 am :
Finally got shit running at 40-50 fps, added a new screenshot to the site. Also the screen shows the new virtual texture lod code.

As soon as I fix the damn memory leak ill get up a build, it will be a client only release(you can still compile the editor code) and it will also be x86.



jmarshall23@Posted: Thu May 10, 2012 4:40 pm :
Test08 released includes x64 and x86 builds. Everyone should hopefuly get around 40-60 fps(I don't drop below 40), next step for me is 32768x32768 : ).

blackenmace.com



BloodRayne@Posted: Thu May 10, 2012 5:03 pm :
Great work al-round so far, jmarshall23!

I'm still somewhat dismayed at the lack of .ase support (or did I miss something along the way?) which makes this completely unviable for Grimm Quest. But I hope some other neat projects will be based on it in the near future. :)



whitewolf@Posted: Thu May 10, 2012 6:07 pm :
It does not work on my machine. I have .net v4 and vcredist installed. (I don't know what version, can you point me to the latest one? I do know its later than 2010). I have the latest directx as well. I put the test8 folder in /doom3/...

I'm on an AMD x4 810, GeForce 9500 GT.

Code:
Stack Trace:
...Function: <invalid> Address: 063DF244
...Function: <invalid> Address: 007248F5
...Function: <invalid> Address: 008AF06D
...Function: <invalid> Address: 008A9E52
...Function: <invalid> Address: 008A9E1B
...Function: <invalid> Address: 0089D0E9
...Function: <invalid> Address: 0089CF80
...Function: <invalid> Address: 0089F5B0
...Function: <invalid> Address: 0046FB47
...Function: <invalid> Address: 4BA32E94
...Function: <invalid> Address: 4B6B159D
...Function: <invalid> Address: 4BC2777D
...Function: <invalid> Address: 4BA444F4
...Function: <invalid> Address: 4BA44240
...Function: <invalid> Address: 4BA3811A
...Function: <invalid> Address: 4BA3837D
...Function: <invalid> Address: 4BA38241
...Function: LdrInitializeThunk Address: 7C90118A
...Function: LdrDisableThreadCalloutsForDll Address: 7C91E024
...Function: FreeLibrary Address: 7C80AC87
...Function: <invalid> Address: 007240BC
...Function: <invalid> Address: 0046879E
...Function: <invalid> Address: 004697C8
...Function: <invalid> Address: 00468ED6
...Function: <invalid> Address: 0045AD87
...Function: <invalid> Address: 00467B1D
...Function: <invalid> Address: 00451514
...Function: <invalid> Address: 00451F1D
...Function: <invalid> Address: 004BC516
...Function: <invalid> Address: 00467ECB
...Function: <invalid> Address: 007262AC
...Function: <invalid> Address: 008AFC22
...Function: <invalid> Address: 008AFACF
...Function: RegisterWaitForInputIdle Address: 7C817067



razvanab@Posted: Thu May 10, 2012 6:18 pm :
Doesn't work for me.

my specs:
2 GB Ram
1,8 Ghz dual core Cpu
1024 GB Ram GeForce GT 220


Code:

WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/an/fontImage_12.dat'
Could not register font fonts/an [fonts/english/an]
WARNING: Couldn't load image: guis/assets/scrollbarv - DEFAULTING
WARNING: Couldn't load image: guis/assets/scrollbar_thumb - DEFAULTING
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: Couldn't load image: guis/assets/mainmenu/cframe_small2 - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/button_cornerangle - DEFAULTING
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: Couldn't load image: guis/assets/mainmenu/buttong_cornersquare2 - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/buttong_middlesm2 - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/buttong_cornerangle2 - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/doom3_3 - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/doom3_2 - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/doom3_1 - DEFAULTING
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: Couldn't load image: guis/assets/mainmenu/content_smallcorner - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/content_glow2 - DEFAULTING
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: Couldn't load image: guis/assets/mainmenu/buttong_cornersquare - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/buttong_middlesm - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/buttong_cornerangle - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/boxframe - DEFAULTING
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: Couldn't load image: guis/assets/common/mlogo - DEFAULTING
WARNING: Couldn't load image: guis/assets/marscity/textblur - DEFAULTING
WARNING: Couldn't load image: guis/assets/marscity/cursor - DEFAULTING
WARNING: Couldn't load image: guis/assets/marscity/bar - DEFAULTING
idFileSystem::OpenExplicitFileRead - reading from: C:\Users\Razvan\Documents\Deadly Law\base\..\base\deadlykey
session initialized
--------------------------------------
--- Common Initialization Complete ---
------------- Warnings ---------------
during Deadly Law initialization...
WARNING: Base Path contains mod folder, ignoring game cvar

WARNING: Couldn't load image: guis/assets/caverns/testmat2 - DEFAULTING
WARNING: Couldn't load image: guis/assets/common/addhighlight - DEFAULTING
WARNING: Couldn't load image: guis/assets/common/addhighlight2 - DEFAULTING
WARNING: Couldn't load image: guis/assets/common/blood - DEFAULTING
WARNING: Couldn't load image: guis/assets/common/dirt3 - DEFAULTING
WARNING: Couldn't load image: guis/assets/common/mlogo - DEFAULTING
WARNING: Couldn't load image: guis/assets/common/outershadow - DEFAULTING
WARNING: Couldn't load image: guis/assets/common/pentagramfx - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/boxframe - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/button_cornerangle - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/buttong_cornerangle - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/buttong_cornerangle2 - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/buttong_cornersquare - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/buttong_cornersquare2 - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/buttong_middlesm - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/buttong_middlesm2 - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/cframe_small2 - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/content_glow2 - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/content_smallcorner - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/doom3 - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/doom3_1 - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/doom3_2 - DEFAULTING
WARNING: Couldn't load image: guis/assets/mainmenu/doom3_3 - DEFAULTING
WARNING: Couldn't load image: guis/assets/marscity/bar - DEFAULTING
WARNING: Couldn't load image: guis/assets/marscity/cursor - DEFAULTING
WARNING: Couldn't load image: guis/assets/marscity/textblur - DEFAULTING
WARNING: Couldn't load image: guis/assets/scrollbar_thumb - DEFAULTING
WARNING: Couldn't load image: guis/assets/scrollbarv - DEFAULTING
WARNING: Couldn't load image: guis/assets/test/faces - DEFAULTING
WARNING: Couldn't load image: guis/assets/test/facesov3 - DEFAULTING
WARNING: Couldn't load image: guis/assets/test/gui_scanline4 - DEFAULTING
WARNING: Couldn't load image: guis/assets/test/gui_scanline4a - DEFAULTING
WARNING: Couldn't load image: guis/assets/test/mask - DEFAULTING
WARNING: Couldn't load image: guis/assets/white - DEFAULTING
WARNING: Failed to load main menu world maps/game/mainmenu_world

WARNING: file materials/patd.mtr, line 4069: Bad term 'staticatable'
WARNING: file materials/patd.mtr, line 4069: expected ',' but found '['
WARNING: file materials/pk01.mtr, line 77: material 'textures/pk01/pk01_floor01b' previously defined at materials/pk01.mtr:53
WARNING: Non-portable: path contains uppercase characters: base/F:\Game_Engines\test08\base\generated\script/script
WARNING: Non-portable: path contains uppercase characters: base/generated/F:\Game_Engines\test08\base\generated\script/script
WARNING: R_Mode >= s_numVidModes, defaulting...

WARNING: RegisterFont: couldn't find font: 'fonts/english/an/fontImage_12.dat'
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
WARNING: RegisterFont: couldn't find font: 'fonts/english/fontImage_12.dat'
45 warnings
--------- Game Map Shutdown ----------
--------------------------------------
reloading guis/mainmenu.gui.
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/an/fontImage_12.dat'
Could not register font fonts/an [fonts/english/an]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
reloading guis/restart.gui.
reloading guis/gameover.gui.
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
WARNING: RegisterFont: couldn't find font: 'fonts/english/bank/fontImage_12.dat'
Could not register font fonts/bank [fonts/english/bank]
reloading guis/msg.gui.
reloading guis/takeNotes.gui.
reloading guis/intro.gui.
WARNING: idImage::Bind: tried to bind image with invalid handle, loading image

--------- Map Initialization ---------
Map: testmaps/terrtaintest2
Init VT Heap 308281364
WARNING: GL_CheckErrors: GL_OUT_OF_MEMORY

49 30 1280 720
Regenerated world, staticAllocCount = 0.
--------- Game Map Shutdown ----------
--------------------------------------
idRenderSystem::Shutdown()
Shutting down OpenGL subsystem
...wglMakeCurrent( NULL, NULL ): success
...deleting GL context: success
...releasing DC: success
...destroying window
...restoring hardware gamma: success
...shutting down QGL
...unloading OpenGL DLL
------------ Game Shutdown -----------
--------- Game Map Shutdown ----------
--------------------------------------
Shutdown event system
--------------------------------------
****FAILURE**** System is now crashing...
f:\dd\vctools\crt_bld\self_x86\crt\src\dbgheap.c(1322) : Assertion failed: _CrtIsValidHeapPointer(pUserData)


Crash dump will contain symbols...
Stack Trace:
...Function: <invalid> Address: 06EAD9A0
...Function: PtexFilter::getFilter Address: 010C48F5
...Function: PtexFilter::getFilter Address: 0124F06D
...Function: PtexFilter::getFilter Address: 01249E52
...Function: PtexFilter::getFilter Address: 01249E1B
...Function: PtexFilter::getFilter Address: 0123D0E9
...Function: PtexFilter::getFilter Address: 0123CF80
...Function: PtexFilter::getFilter Address: 0123F5B0
...Function: PtexFilter::getFilter Address: 00E0FB47
...Function: GetGameAPI Address: 6C002E94
...Function: GetGameAPI Address: 6BC8159D
...Function: GetGameAPI Address: 6C1F777D
...Function: GetGameAPI Address: 6C0144F4
...Function: GetGameAPI Address: 6C014240
...Function: GetGameAPI Address: 6C00811A
...Function: GetGameAPI Address: 6C00837D
...Function: GetGameAPI Address: 6C008241
...Function: wcsncmp Address: 77858968
...Function: RtlGetDaclSecurityDescriptor Address: 77822708
...Function: LdrUnloadDll Address: 7785C8B8
...Function: <invalid> Address: 7596873A
...Function: PtexFilter::getFilter Address: 010C40BC
...Function: PtexFilter::getFilter Address: 00E0879E
...Function: PtexFilter::getFilter Address: 00E097C8
...Function: PtexFilter::getFilter Address: 00E08ED6
...Function: PtexFilter::getFilter Address: 00DFAD2B
...Function: PtexFilter::getFilter Address: 00F0D907
...Function: PtexFilter::getFilter Address: 00EFFD2E
...Function: PtexFilter::getFilter Address: 01234EFA
...Function: PtexFilter::getFilter Address: 01235CE6
...Function: PtexFilter::getFilter Address: 00FC811B
...Function: PtexFilter::getFilter Address: 00E8D94A
...Function: PtexFilter::getFilter Address: 00E8BFEC
...Function: PtexFilter::getFilter Address: 00E8BE0F
...Function: PtexFilter::getFilter Address: 00E93A2E
...Function: PtexFilter::getFilter Address: 00DF1514
...Function: PtexFilter::getFilter Address: 00DF1F1D
...Function: PtexFilter::getFilter Address: 00E5C516
...Function: PtexFilter::getFilter Address: 00E07ECB
...Function: PtexFilter::getFilter Address: 010C62AC
...Function: PtexFilter::getFilter Address: 0124FC22
...Function: PtexFilter::getFilter Address: 0124FACF
...Function: BaseThreadInitThunk Address: 7696ED6C
...Function: RtlInitializeExceptionChain Address: 7786377B
...Function: RtlInitializeExceptionChain Address: 7786374E
A crash has a occurd please review the console for any information related to this crash
Shutting down OpenGL subsystem
...restoring hardware gamma: success
...shutting down QGL





jmarshall23@Posted: Fri May 11, 2012 12:46 am :
You need atleast 3gb of ram (the app takes up like 1.3 gigs at the moment) , off hand if its crashing that means its probably running out of memory, and it uses around 1gb of vram it also could be your running out memory on the card. The code isn't optimized at the moment(which is why I held back from a x86 release), but thats good to know I have to get the memory consumption down.

Quote:
WARNING: GL_CheckErrors: GL_OUT_OF_MEMORY


Yup your running out of video memory.

Quote:
GeForce 9500 GT


That card only has 256-512mb of ram which isn't anywhere close to whats required to run the current build. I'm going to see if I can get down the amount of memory required to run the engine, but I hope this drives home the finer points that the editor requires a good amount of ram to run; and when I get in GI some of it is def going to have to be baked into the vt, x86 cpu's just aren't powerful enough to handle the extensive amount work required to make a good size vt.



jmarshall23@Posted: Fri May 11, 2012 2:56 am :
On the bright side im testing the current codebase with a 32768x32768 Virtual Texture and its running at 30fps.



rich_is_bored@Posted: Fri May 11, 2012 4:36 am :
PtexFilter? Would that be referring to this Ptex?...

http://ptex.us/



jmarshall23@Posted: Fri May 11, 2012 4:46 am :
Yes it does, I haven't commited the code to support ptex yet(as a lot of people bitched against it so I never really cared to update that code to the current codebase), but the ptex library is in the codebase. If its jumping to that code that means there was some kind of heap problem, and since there running out of memory/vram thats why its showing in the stack trace.



jmarshall23@Posted: Fri May 11, 2012 5:48 am :
Also just uploaded a quick test image of a 32768x32768 vt to the site.



whitewolf@Posted: Fri May 11, 2012 10:20 am :
jmarshall23 wrote:
That card only has 256-512mb of ram which isn't anywhere close to whats required to run the current build.


The version of the card I bought has 1gig of ram.



jmarshall23@Posted: Sat May 12, 2012 1:00 am :
Drr for those getting the GL_OUT_OF_MEMORY error change r_backend_shadowMapCacheSize to 1024 or even 512 that will lower the memory consumption so you guys can run it.



razvanab@Posted: Sat May 12, 2012 1:42 am :
Great
Thanks !



jmarshall23@Posted: Sat May 12, 2012 6:59 am :
Did that fix it?



jmarshall23@Posted: Sat May 12, 2012 9:04 am :
Omg I feel so stupid I figured out why my shit was taking up a gig of memory. Somehow I changed the values in trisurf to insane values so it was generating 1gb of mesh storage!

Other fixes(rev 69):
Made idDict values global(strpools are in common).
Fixed the font loading issue(guis now render correctly).
Fixed a nasty bug in trisurf where it was allocating 1gb worth of tris storage.
Fixed the UI Editor
Fixed a bug where duplicating stuff in the UI Editor would crash.
The UI Editor now draws in ui debug mode.



tea monster@Posted: Sat May 12, 2012 11:54 am :
Whoo-hoo! :D

One thing, I've been thinking about ptex. Yes, it's not really a 'well honed feature' in game modding, but if you consider that you are basically supporting (in effect) auto-uv mapping, it would shave a LOT of time off of development. ZBrush does something similar with it's auto UV, and as long as you stay within ZBrush, it seems to work OK.

The big problem with this is going to be baking normal maps. How you unwrap an item can have a huge impact on how the bake turns out. This is particularly true with hard-surface stuff (in our case props and weapons).

If that can be made to work though it would be great. Work-flow that would allow you you to dump uv mapping would be a huge time-saver.

When are we getting the "Noobs Guide to Teh Awesomeness"?



razvanab@Posted: Sat May 12, 2012 9:55 pm :
yes now the map loads with r_backend_shadowMapCacheSize to 512



jmarshall23@Posted: Sat May 12, 2012 10:15 pm :
Quote:
One thing, I've been thinking about ptex. Yes, it's not really a 'well honed feature' in game modding, but if you consider that you are basically supporting (in effect) auto-uv mapping, it would shave a LOT of time off of development. ZBrush does something similar with it's auto UV, and as long as you stay within ZBrush, it seems to work OK.

The big problem with this is going to be baking normal maps. How you unwrap an item can have a huge impact on how the bake turns out. This is particularly true with hard-surface stuff (in our case props and weapons).


With PTextures there are no UV's, so you dont even have to unwrap anything. ZBrush doesn't support ptex yet to my knowledge(only mudbox since thats what Disney/Pixar uses exclusively). Now how you essentially render each face of the ptex is each quad is mapped 0->1, and than you have to do a couple nasty things to fix the edges.

Now I haven't worked with professional artists yet on PTex workflow, but essentially in my tests its all the same as before just take out anything UV related in your workflow.

Quote:
When are we getting the "Noobs Guide to Teh Awesomeness"?


I keep on meaning to knock out a guide just been putting it off. I plan on releasing a editor build sometime with in the next few days ill knock out a guide than. I can't do a fraps video cause with 8gb of ram mudbox bogs down with a 32768x32768 vt.

Someone asked on my forum about the specs of the pc im using.

Geforce GTX 560 2gb of VRam
8gb Virtual Texture
Intel Core 2 Quad 2 2.50ghz.

I really need to upgrade my ram to 16gb.



jmarshall23@Posted: Sun May 13, 2012 2:36 am :
Got a new screenshot up of the current code(rendering stuff modifications mostly) but I painted everything more matisculuslly and for testing I used textures from the QW megatexture pack.

blackenmace.com



rich_is_bored@Posted: Sun May 13, 2012 5:45 am :
There's a custom build of Blender that supports Ptex. I don't know if it will ever make it into trunk but the videos are pretty badass.

http://vimeo.com/19845292



whitewolf@Posted: Sun May 13, 2012 8:22 am :
r_backend_shadowMapCacheSize to 512 gets the game to load for about 2 seconds before it crashes, and even then I can see the textures are all glitched up like a dot matrix. The debug just gives me generic shit like function <invalid> address and unhandledexceptionfilter.

Damn I would really like to experience teh awesomeness too.



jmarshall23@Posted: Sun May 13, 2012 9:51 am :
There was something stupid I was doing in that release that made it take up way too much ram. Based on your description that's probably it and has been fixed, my next release is going to be a editor only release. It will include the map models but no prebuilt vt. I want to get ppl used to painting shit.



jmarshall23@Posted: Thu May 17, 2012 8:54 pm :
Just got back from vaccation and relized my forum was bombarded with spam bots :P, I fixed it and ill reactivate the forum in a few hours.



jmarshall23@Posted: Fri May 18, 2012 8:59 am :
Board is back up, I also fixed the tile border issue and uploaded a vid showing off the code(its on the main page at blackenmace.com). Fixed the spam bot issue too I think :/.



jmarshall23@Posted: Sat May 19, 2012 11:11 pm :
New stuff in the svn:

Sky portals now work(new screenshot on the site).
New option to set a static mesh to NOT be part of the vt(this is needed for skies).
Added a new compile option to opt out of updating the virtual texture.
All the tools that were still present in the exe(dmap, aas, vt builder) are now moved to the tools dll.

blackenmace.com
Home of the IdTech4 CDK



The_Raven@Posted: Sun May 20, 2012 1:15 am :
I haven't posted in awhile, but I have continued to follow any and all developments on the project. One question, though: Is it just going to be static meshes that have the ability to not be included in the vt or will this be expanded to brushes as well? I know at some point you mentioned that you were looking into making virtual textures for most stuff to be optional in order to make the engine more indie friendly. Is this a start towards this process or is this something else?



jmarshall23@Posted: Sun May 20, 2012 1:22 am :
With a quick code change in the game dll you can completely opt out of virtual texturing if you wanted to. This flag as of now is only for static meshes, this is used at the moment for the sky dome, but this also can be useful for saving texture space in the vt. For example you can have half of a tree part of the vt that's got bark plus snow on it and the rest of the tree isnt part of the vt and rendered normally.



The_Raven@Posted: Sun May 20, 2012 1:38 am :
I think I grasp your example with the tree, these concepts are still new to me. Hopefully I'm not being a pest, but what advantages would there be to keeping the skydome and the top half of the tree outside the virtual texture? While neither of these examples need to be painted or blended, it was my understanding that one of the advantages of virtual textures was that it was more memory efficient to have all of one's geometry and mesh texture data baked into a single large texture for optimal streaming?

Good to hear that opting out of virtual texturing is just a simple code change for those who might not have enough RAM for the intensive baking process.



jmarshall23@Posted: Sun May 20, 2012 1:52 am :
Your not being a pest stop that :).

These are very new concepts for a huge portion of the game industry so don't feel bad at all. Most devs will only be able to build a 32k vt or at most a 64k vt. That's still not as much space as you would think. A way to optimize your levels to sqeeze out as much detail as you possibly can. If you can have some of your static meshes not part of the vt, you have more vt real estate you can allocate some place else.

Everything you listed about vt is true, but the biggest advantage is you control each pixel on each piece of geometry in your level. The bad part is all static meshes are inlined so your very counts can get pretty high. Going back to the tree you could also have that part of the tree with a higher very count and repeated all over the place, which would save storage space on the graphics car, and could speed up your scene.



The_Raven@Posted: Sun May 20, 2012 1:58 am :
That makes sense.

Thanks.



Gir@Posted: Sun May 20, 2012 5:23 am :
jmarshall23 wrote:
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.


Could the GUI use vector graphics, so it looks crisp in any Resolution ?

Also, will you be Implementing Gamepad Support (Xinput API)



jmarshall23@Posted: Sun May 20, 2012 7:45 am :
Vector graphics for guis are def on my to do list among 900 other features :). Xinput is also a great idea but ill be looking into kinect integration before that.
all of which is currently a priority 2 feature.



jmarshall23@Posted: Fri May 25, 2012 11:38 pm :
New stuff in svn:

Shadows now have feathered edges
Post process shaders fixed(per-material programs are also fixed).
Fixed a nasty bug that models that weren't part of the VT would draw without depth testing.

Uploaded a new vid of the current svn to the site.

blackenmace.com
Home of the IdTech4 CDK



Gir@Posted: Fri May 25, 2012 11:53 pm :
looks impressive :)

Can't wait to test it.



Gary@Posted: Sat May 26, 2012 12:11 am :
Website won't load. 404.



jmarshall23@Posted: Sat May 26, 2012 12:27 am :
Should work now I really need to move to a new web host.



jmarshall23@Posted: Thu May 31, 2012 9:37 pm :
I made some changes to the VT file format. The new file format ensures that I get the same speed reading from the HD as I did when reading from memory(its more of a hybrid approach).

A lot of people have also been asking me about the virtualtexture file format I documented the fileformat changes as welll as the file format here:

http://blackenmace.com/phpBB3/viewtopic.php?f=6&t=496



jmarshall23@Posted: Sun Jun 03, 2012 11:58 pm :
New Stuff in SVN:

65kx65k VT Support(the final filesize hovers around 4gb).
New filesystem functions to load larger than 2gb files.
You can now select faces in the editor.
You can now mark surfaces as nodraw.
Added/Fixed the Q4 script debugger.



jmarshall23@Posted: Tue Jun 05, 2012 7:43 am :
Got up a quick screenshot of a indevelopment level using 65k vt's(clear your internet cache):

http://blackenmace.com/



jmarshall23@Posted: Fri Jun 15, 2012 12:30 am :
I've been working on in editor paint tools and I've mostly got it working but as you can see from the screenshot edges are currently a issue.

Attachment:
vtpainttools.png
vtpainttools.png [ 255.33 KB | Viewed 236 times ]


Currently I'm tracing a unprojected ray against the world to figure out a) what vt area we hit and b) that point needs to get converted back into 2d coords so we can figure out were to paint. To do the latter I'm using a heavily modified version of idRenderWorldLocal::GuiTrace. The problem is this function is very inacurate on non flat surfaces. My modified function below:

Code:
/*
================
VTTrace
================
*/
vtPoint_t idRenderWorldLocal::VTTrace( int vtAreaId, const idVec3 start, const idVec3 end ) const {
   srfTriangles_t   *tri;
   vtPoint_t pt;
   localTrace_t   local;
   const modelSurface_t *vtsurf = NULL;

   memset( &pt, 0, sizeof(vtPoint_t));

   if(vtAreaId == -1) {
      common->Warning("VTTrace: Can't trace against non vt areas.\n");
      return pt;
   }

   for(int i = 0; i < localModels.Num(); i++)
   {
      idRenderModel *model = localModels[i];

      //common->Printf("Generating Collision for %s - %d collision models\n", model->Name(), model->NumSurfaces() );
      for(int s = 0; s < model->NumSurfaces(); s++)
      {
         const modelSurface_t *surf = model->Surface( s );

         if(surf->geometry->vt_AreaID == vtAreaId) {
            vtsurf = surf;
            break;
         }
      }


      if(vtsurf != NULL)
         break;
   }

   if(vtsurf == NULL) {
      common->Warning("VTTrace: VTArea %d is invalid!\n", vtAreaId);
      return pt;
   }

   tri = vtsurf->geometry;

   local = R_LocalTrace( start, end, 0.0f, tri );
   if ( local.fraction < 1.0 ) {
      idVec3            origin, axis[3];
      idVec3            cursor;
      float            axisLen[2];

      R_SurfaceToTextureAxis( tri, origin, axis, &local.indexes[0], &local.plane );
      cursor = local.point - origin;

      

      int closestIndex = 0;
      if(local.d[0] > local.d[1] && local.d[0] > local.d[2])
      {
         closestIndex = local.indexes[0];
      }
      else if(local.d[1] > local.d[0] && local.d[1] > local.d[2])
      {
         closestIndex = local.indexes[1];
      }
      else if(local.d[2] > local.d[1] && local.d[2] > local.d[0])
      {
         closestIndex = local.indexes[2];
      }

      cursor = local.point - tri->verts[closestIndex].xyz;
      axisLen[0] = axis[0].Length();
      axisLen[1] = axis[1].Length();

      pt.x = ( cursor * axis[0] ) / ( axisLen[0] * axisLen[0] );
      pt.y = ( cursor * axis[1] ) / ( axisLen[1] * axisLen[1] );
      pt.x += tri->verts[closestIndex].st.x;
      pt.y += tri->verts[closestIndex].st.y;
      return pt;
   }

   common->Warning("VTTrace Failed.\n");
   return pt;
}


Basically what makes this function more accurate is I interporlate the position from the nearest point that got hit and extrapolate the final position that way. And it works 90% of the time but its still not as acurate as I need it to be. Has anyone been working on something like this that can provide some insite on what I'm doing wrong?



jmarshall23@Posted: Sat Jun 16, 2012 9:29 am :
Fixed a lot of the bugs with the VTPaintTool still isn't exactly right but got a lot more stuff in including layers, and the BSP compiler(DMap) will build the virtual texture from the MegaProject which means no more MudBox requirements :P. I'll try to release a editor build sometime with in the next week.

http://blackenmace.com/phpBB3/download/file.php?id=16



The_Raven@Posted: Fri Jun 29, 2012 6:52 pm :
Things seem to be quiet as of late since the last commit to the code.google repository was on June 16th with no activity since then. I'm not complaining since I'm fully aware that a lot has been accomplished recently and if jmarshall23 wants to take a bit of a break, then I think he's earned it. I was just wondering what the plan was going forward.

Also, I was looking at the video of the texture painting tool awhile ago and the only comment I can think of is that wouldn't the helper brush that shows where the texture is going to be painted work better if it was a decal that was projected on the terrain? Other than that, things look great so far.



jmarshall23@Posted: Sat Jun 30, 2012 12:59 am :
Quote:
Things seem to be quiet as of late since the last commit to the code.google repository was on June 16th with no activity since then. I'm not complaining since I'm fully aware that a lot has been accomplished recently and if jmarshall23 wants to take a bit of a break, then I think he's earned it. I was just wondering what the plan was going forward.

Also, I was looking at the video of the texture painting tool awhile ago and the only comment I can think of is that wouldn't the helper brush that shows where the texture is going to be painted work better if it was a decal that was projected on the terrain? Other than that, things look great so far.


That just means I haven't checked anything in : ), I'm moving everything over to a git repository I wanted to do a full release when I got most of the bugs fixed ill commit everything in a couple days.

That was just the initial implementation, the brush now properly gets projected on the mesh.



The_Raven@Posted: Sun Jul 01, 2012 9:00 pm :
That sounds great.

I'm probably thinking too far ahead, but what do you think you'll work on next after virtual textures get settled out?



The_Raven@Posted: Tue Jul 24, 2012 6:42 am :
I was just wondering what was currently going on with the project? The website has been down for a few days, so I thought I'd ask.



tea monster@Posted: Fri Jul 27, 2012 11:42 pm :
Same here.



parsonsbear@Posted: Sat Jul 28, 2012 8:04 am :
Haven't been any updates for a while. The last stuff seemed interesting- support for kinect!
http://code.google.com/p/idtech4cdk/source/list



Dashiva@Posted: Sun Jul 29, 2012 5:12 pm :
Yeah he looks like he has a history of stopping interesting projects if you look at the repository. Anyone up for forking it?



AnthonyJa@Posted: Mon Jul 30, 2012 3:29 pm :
It's a bit early for assumptions like that - it is the summer after all!



Dashiva@Posted: Wed Aug 15, 2012 6:05 pm :
I'd say it's pretty much dead at this point. He was going through 1 revision every day or so and then just stopped. I sent him an email asking if this was still going but no dice :/. Seemed like a really cool system.



anonreclaimer@Posted: Wed Aug 15, 2012 6:23 pm :
This project was improving the Doom 3 engine why would he stop.Well we can use his work so he didn't program for nothing.



Dashiva@Posted: Wed Aug 15, 2012 6:37 pm :
I'm not sure. Licensing issues? Anyway, the code is there for forking, someone just needs to take control and do something useful with it.



anonreclaimer@Posted: Wed Aug 15, 2012 8:42 pm :
I don't care about the licensing issues for now I got the source code from the svn and I'm going to make good use of it.



Dashiva@Posted: Thu Aug 16, 2012 5:14 pm :
anonreclaimer wrote:
I don't care about the licensing issues for now I got the source code from the svn and I'm going to make good use of it.


If you do start using it, is there any way you can set up an alternate repo with your changes? I still can't get it to compile, and I don't have the time to troubleshoot it.



jmarshall23@Posted: Sat Mar 10, 2012 5:22 am :
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.



gavavva@Posted: Sat Mar 10, 2012 12:06 pm :
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.



slush_puppy@Posted: Sat Mar 10, 2012 2:22 pm :
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



Dolce Decadenza@Posted: Sat Mar 10, 2012 3:36 pm :
gavavva wrote:
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.


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.



BloodRayne@Posted: Sat Mar 10, 2012 3:43 pm :
Dolce Decadenza wrote:
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.



Dolce Decadenza@Posted: Sat Mar 10, 2012 3:56 pm :
BloodRayne wrote:
Dolce Decadenza wrote:
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



BloodRayne@Posted: Sat Mar 10, 2012 4:43 pm :
Dolce Decadenza wrote:
and not insult him because he posted small screenshots

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



Dolce Decadenza@Posted: Sat Mar 10, 2012 5:04 pm :
BloodRayne wrote:
Dolce Decadenza wrote:
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".



slush_puppy@Posted: Sat Mar 10, 2012 5:04 pm :
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.



Dolce Decadenza@Posted: Sat Mar 10, 2012 5:38 pm :
slush_puppy wrote:
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...



BloodRayne@Posted: Sat Mar 10, 2012 6:31 pm :
Dolce Decadenza wrote:
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..

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?



jmarshall23@Posted: Sat Mar 10, 2012 7:36 pm :
First off excelent critiques! BloodRayne had some excellent points, please don't deter anyone from speaking their mind :).

Quote:
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.


Programmer Art :).

Quote:

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?



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).
Quote:
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.


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

Quote:
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...


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

Quote:
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 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.

Quote:
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.


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.

Quote:
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.


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

Quote:
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?


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.



Dolce Decadenza@Posted: Sat Mar 10, 2012 7:41 pm :
BloodRayne wrote:
Dolce Decadenza wrote:
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..

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.


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)

Quote:
- 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 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.

Quote:
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?


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.



=FF=Sturm@Posted: Sat Mar 10, 2012 7:43 pm :
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

Image



jmarshall23@Posted: Sat Mar 10, 2012 7:56 pm :
=FF=Sturm wrote:
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...


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 :P). 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?



=FF=Sturm@Posted: Sat Mar 10, 2012 7:59 pm :
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.



Dolce Decadenza@Posted: Sat Mar 10, 2012 8:06 pm :
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!



jmarshall23@Posted: Sat Mar 10, 2012 8:07 pm :
=FF=Sturm wrote:
Upgraded physics and multicore support for both CPU/GPU are a must. (OpenCL cap.)
Encryption system for pk4 files in order to don't steal code/assets without releasing the sources by the autor.


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.

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


I'll check that right now : ).



slush_puppy@Posted: Sat Mar 10, 2012 8:48 pm :
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.



jmarshall23@Posted: Sat Mar 10, 2012 9:07 pm :
slush_puppy wrote:
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.