Path: chuka.playstation.co.uk!news From: Robert_Swan@scee.net (Robert Swan) Newsgroups: scee.yaroze.programming.3d_graphics Subject: Re: race game 3 design: step 1 Date: Wed, 01 Mar 2000 10:00:31 GMT Organization: PlayStation Net Yaroze (SCEE) Lines: 64 Message-ID: <38bce729.1480649@www.netyaroze-europe.com> References: <38ada944.33392524@www.netyaroze-europe.com> <89hr2n$9dj2@chuka.playstation.co.uk> Reply-To: Robert_Swan@scee.net NNTP-Posting-Host: mailgate.scee.sony.co.uk X-Newsreader: Forte Free Agent 1.11/32.235 On Tue, 29 Feb 2000 19:16:23 -0800, "Nathan Miller" wrote: >Unless there is a specific need to have a dynamically morphed track, you >could have pre-made track section tmds at different LODs and then modify >their y component to fit the curve (up and down). As far as left and right, >this would be much harder, but you may think of limiting yourself to set >track pieces. Then again, you could have a lookup table to find the values >you need to shift the x and y components for the lod tmd (to make different >angles on turns etc.) >I am thinking that this would be easier and a lot less computationally >expensive on the processor, allowing for better physics etc. >Then there is the issue of memory, several LODs and some working area would >definately pile up after a while, but it shouldn't hurt too bad, since you >could load all of the sounds and use that space for work area. Ive realised that maybe I havent explained everything - meaning it looks wierd on some of the assumptions Im making. Hopefully most things will make sense with examples - but until I get my source code back from my brother I would have to rewrite a lot of the stuff Ive already done! (which obviously I dont want to do). Basically the idea is to rip off Wipeout. It is a track based game but quite cleverly you tend not to get too close to the scenery so that can have less time wasted on sorting out subdivision etc. The reason Ive set up this runtime LOD is to remove all the cracks in the scenery and to avoid the stepping that is prevelent in most LOD stuff (mipmapping, subdivision, whatever). It should work out better in terms of memory - I was thinking of each section of track (probably about 100) being unique. To store 100 * hi detail models and 100 * very low details models + workspace for one hi detail morphed model is much less than say 100 * hi detail + 100 * mid detail + 100 * lo detail - and seeing as some work is going to be done on stitching up the gaps between models of different details (check steve collins demo to see what a difference it makes, and how annoying T-junctions are) I figured I might as well go the whole distance and allow for complete creation of sections of track. In yaroze games we tend to throw quite a lot of polys at the computer and have cpu time to spare - Im trying to even things out. If I can get my head around it - Im thinking of trying single buffering the OTs - massive memory savings available which can be chucked back into models, etc - god help me >All this is just a thought, you are the real game programmer! :-) ahem, yes - it means my mistakes cause problems other than just to myself :) None of the stuff Im doing is necassarily the fastest or best method - but doing the work I am you dont get to see every side of games programming, so these are just little exercises to try to keep my mind a bit more active. BTW - Spyro 2 is pretty amazing technically - they are doing so much stuff. Gods knows how they manage all their calculations. Ive just heard that they modify the central vertices of polys that have just been subdivided - to counteract the 'snapping' between levels of subdivision. Now _thats_ attention to detail. (IMHO) Rob Disclaimer: Anything I say has no direct relation to where I work (Sony), is not an official voice of where I work (Sony) and Sony doesn't even exist as far as I'm concerned.