 |
|
You are not logged in! F.A.Q Log in Register |
 |
|
 |
 Now online (2)dariusgriffin big ...and 184 guests Last 5 registered Oplandisks nothingstar N_loop yipe foxtrotromeo Browse members... |
 |
Members 8025Messages 2615481 Today 14 Topics 127653 |
|
|||||||||
| |||||||||
|
|
i'm not sure whether you're being serious, or having a go at me lol if you're serious, i might take you up on that later it's been a while since i had a bash on Q3A, so i'll probably be a bit rusty |
||||||||
|
|
|||||||||
| |||||||||
|
|
thought so, I know there using some of the newest features of Graphics cards and perhaps this is a reason why no games are a small yet, they may be still in production. perhaps Doom4 fits onto an FDD. ;-) -- DoctorMO -- |
||||||||
|
|
|||||||||
| |||||||||
|
|
nah, that'll never happen id Software want too much control over their games, and rightfully so that'd be like wanting to make an amazing track, but only using General MIDI and getting the computer to do most of the notes and shit. id Software regard game making as an art :) |
||||||||
|
|
|||||||||
| |||||||||
|
|
Not if everything was stored procedurally... I'm doing procedural texturing as my major project for my degree. You can fit huge amounts of output data into a tiny (filesize wise) definition. Just think of sound synthesis and midi- midi files are minute, as are softsynth patches. However, combine them together and you get huge output files. The same can be done for textures, in game sounds, music, 3d models, etc. coupled with using bits of code/libraries already on PCs to handle 3d (XML, etc.) or even writing it all in x86 machine code from the ground up and then compressing the whole file down, you can store what results in a very complex program in a very small space. |
||||||||
|
|
|||||||||
| |||||||||
|
|
Erm just read the thread in full and a lot of people pointed out some of the stuff I did. Sorry for the repeats... |
||||||||
|
|
|||||||||
| |||||||||
|
|
yeah but the only reason that when you combine MIDI and synths and you get massive output, is because the MIDI is just controller data for the synths i don't think it'd be an easy task to get some code to basically "synthesize" Adrian Carmack's artwork ;) |
||||||||
|
|
|||||||||
| |||||||||
|
|
Graphical synthesis is just as simple as audio synthesis... a huge range of graphical textures (wood, water, stone, flesh, gore, etc.) can be made from little more than filtered noise, which can be abstracted as a basic array of the numbers 0 through to 256 ordered randomly (which can of course itself be defined in a few lines of code). The synthesis modules as it were are simple small blocks of code that perform basic mathematical functions on this array. The combination of these simple synthesis modules with different variables are what allow the huge output. I expect as processing power increases procedural textures will be used more and more for most (organic/natural at least)textures in games. Even in something as old as UT1, the high res textures run to well over 100mbs. As resolutions increase and character models get more complex this will increase to stupid amounts if we stick to bitmapped textures. |
||||||||
|
|
|||||||||
| |||||||||
|
|
I do accept that for "artistic" stuff like stained glass windows, details on equipment, etc. they'll still be done by artists though :) |
||||||||
|
|
|||||||||
| |||||||||
|
|
yeah, i totally agree with you - this kind of thing would be great for natural looking surfaces or grainy stuff like concrete or stone of something, but i dunno.....i think that most companies will still opt for the artistic control over file size - don't forget that hard drives are getting bigger too, and cheaper, and distribution media is getting larger (although i have yet to see a commercial game for PC or Mac released on a DVD, maybe i'm wrong on that, but i've never seen one yet) it'd be interesting to see where this technology goes :) |
||||||||
|
|
|||||||||
| |||||||||
|
|
You do get commercial games on DVD, although it is rare... one of the multi-disc D&D ones was re-released as single disc DVD and I believe the first ever was Microsoft's "Lander". For animated things like water (until we get the proccessing power for accurate, real time, procedural particle modelling, which is some way off) and lava procedural textures are great. Helps eliminate that "looping" that you can see on bitmapped ones. |
||||||||
|
|
|||||||||
| |||||||||
|
|
what does the water in HL2 use, do you reckon? i think some of the technology in that game is fucking mind blowing, especially as it runs in real time (but then again, that demo could have been on a mega system!) |
||||||||
|
|
|||||||||
| |||||||||
|
|
I've not seen any water in the clips I've seen, so I can't really comment, but I would imagine they are done procedurally. I should stop talking about procedural textures... I've got over 100 pages to do on them in the next week as well as more coding. I'll be sick of them by the end ;) It's a fascinating area though, studying it has improved my understanding of audio synthesis (in terms of what's happening at a code level) loads. Just do a google for: "Perlin Noise" Procedural textures for lots of good info. |
||||||||
|
|
|||||||||
| |||||||||
|
|
ahh well, in the full length clip on gamespy, there's a bit where the player walks through water and stuff, shoots barrels and stuff into a swimming pool, and the water looks amazing for a game :) i'm not a coder, so i'm not sure that it would mean much to me....i know enough about computers and stuff to understand the logic of how they work, but i just can't cut it when it comes to programming the most coding i ever did was configuring LiteStep on my PC!! and that can't really be classed as coding, can it ;P |
||||||||
|
|
|||||||||
| |||||||||
|
|
sorry -V- and everyone.... i didn't see it *' _ '* is the original link. |
||||||||
|
|
|||||||||
| |||||||||
|
|
ok procedural texturing makes sense for a lot of things, even if you did a bitmap texturing for say a device and then a procedural rust texture or burn texture. no more similar looking burn marks! -- DoctorMO -- |
||||||||
|
|
|||||||||
| |||||||||
|
|
ahhh this reminds me of our conversation a while back, remember? when we first saw the preview of HL2? we were talking about how it'd be cool if they could randomize things such as clothing, and marks on the clothes, and cuts and scars on the characters and stuff i guess this is the thing that can be used for that :) |
||||||||
|
|
|||||||||
| |||||||||
|
|
Part of what the end of this project clarifies (and about 1/3 of my hypothesis stated) was that in the near future, we will probably see hybridisation of the two like you suggest- Until processing power gets obscenely powerful bitmapped (and by that I just mean pre-rendered, includes other formats like .jpg, etc.) there's be a use for both, often overlayed together- eg, procedurally drawn oil/petrol on a floor textured with tiles depicting a picture, like a mosaic, or bruises on faces of characters (I really reckon we'll see bruises that "develop" as the rounds progress in boxing games), blood soaking through clothes, etc. re: rust- there's an awesome model (I can't remember where, but I'll post a link if I remember) of rust being added in real time to a model- it was sort of like time lapsed photography, but it wasn't just textured in rust, you could see the smooth surfaces become pitted (bump mapped) and flakes of rust fall off, holes appeared in places etc. Procedural modelling is a lot harder to get right (particlarly on things like humans), but eventually we may well see them being used for real time corrosion, burns (say acid in the next aliens game) melting, etc. |
||||||||
|
|
|||||||||
| |||||||||
|
|
well I hope it just ends up in a couple of games so we can give it a good test run. |
||||||||
|
|
|||||||||
|
Messageboard index
|
|||||||||
