Huge terrains and the Fire Service
Blitz3D Forums/Blitz3D Beginners Area/Huge terrains and the Fire Service
| ||
| Hi, I work for a large metropolitan Fire Service in England, UK. We were recently given some terrain data to have a play with (x,y and altitude) that covers our entire Fire Brigade area. We’ve got some cool ideas what we can do with this stuff (calculating where chemicals will “run off” if dropped, flooding visualisations, 3D views of major sites, 3D tracking of fire trucks etc.) but we’ve only a small amount of 3D programming experience. So… we’ve got a massive grid of 10,800 x 7200 points (which equates to a height measurement taken for every 5m square in our Brigade area). For each point I get an indication of if it is grass/road/water/building etc as well, which might make things look even better. In the future I can get the floor plans and heights for all the buildings, but I think that might be getting ahead of myself...I’ll stick with just trying to generate some terrain for now! I would like to retain as much of this “5 metre resolution” as possible around the camera so we can accurately model the chemical run-off as mentioned earlier. But as well I would like to be able to generate much bigger LOD-based landscapes as well for other applications. Has anyone got any suggestions about how to get going with rendering a huge terrain like this? After reading plenty of threads in these forums I’m not too sure what the best way forward is. I think I’ll need the works… not sure of the terms, but shading, shadows, alpha-blending (is it?) etc… most importantly - not an insurmountable learning curve! I’ve settled on Blitz3D as my weapon of choice for knocking up prototypes and quick apps (and I really enjoyed BB on the Amiga and fancied get back into it!). We have very little budget, and our PC’s are “reasonable”, but certainly not state-of-the-art game machines. Any suggestions about a suitable engine (that is really easy to get going in Blitz3D!) or even any general tips would be really appreciated. Thanks for your time. Tim |
| ||
| Is this you?: Tim Needham, of the West Midlands Fire Service, fought off several other top candidates to become 2006’s IT Professional of the Year. The senior systems developer delivered his groundbreaking vision for an Integrated Risk Management Information System (Irmis) in May 2005. In its first year the system captured the details of more than 60,000 varied activities from 1,500 employees in richer detail than ever before, enabling the brigade to work more productively in ways that previously had not been possible. Needham also consistently demonstrated an ability to use his technical talent to meet business objectives. For example, the exceptional quality of the user interface he developed for Irmis reduced the need for user training. Needham was also singled out for his softer skills, including the ability to convey his ideas in a way that captures people’s imagination and inspires the organisation to action. This seems a very large and complex project. However, 'Blitzland' does have various terrain experts. To set the ball rolling: The size of the terrain will probably not matter as it could be split into chunks. However, this project will certainly need a physics engine too and terrain splitting might then be problem. I don't use any physics engines, so not to sure how much custom coding would be required. What mesh format is this massive terrain in? Any idea of the number of polygons/triangles in it? What is the file-size of it (how much hard disk space does it take?). |
| ||
| Hi Puki, Errm… never met the bloke, sounds a right clown... ;) Haven’t got the final data just yet, but we’re told it ships as several huge (not sure of the exact size) comma-delimited text files (x,y,z). I’m resigned to writing some intermediary conversion/processing stage. Perhaps writing something that could process these filea and produce lots of imagemaps is the way to go? But then won’t that limit me to having 256 “terraces” (perhaps losing all the subtleties in the data?) All-in it’s looking like 77million points though…not sure how to turn that into an exact triangle count, but guessing it’ll weigh in as more than that? Like you say I’m sure it’ll all need splitting into chunks, any ideas about optimal sizes and (physic issues aside for now!) how best to load them as-and-when needed? Thanks Tim |
| ||
| split it into 256 sized imagemaps and use those for your chunks. |
| ||
| Hi Tim77, It seems that "T.ED TERRAIN & WORLD EDITOR" and "JV-ODE" could help the integration of terrain and physics. http://www.d-grafix.com/?page=ted http://www.freeforum101.com/forum/viewtopic.php?t=9&highlight=jvode&mforum=dgrafix :) |
| ||
| Splitting it may be the way to go. But, i'd avoid using blitz terrains. Make your own terrains, out of a mesh. It may lack LOD, but it's far faster, as blitz terrains calculate LOD every frame, and you get some degree of vertices popping. I'm concerned about the lack of accuracy though, you'll get using standard physics engines, for simulating water. Such things like pourus rocks, soil absorbing liquid, various land features altering the flow of liquid... etc etc. I don't think it will be a very accurate simulation. For 3d tracking of fire trucks, it would be a good idea i guess though :o) |
| ||
| I might be able to help you Tim77 if you havent got it going yet. Email me GameMaker04@... |
| ||
| Wow! Thanks for all the feedback on this… really appreciated! I think I’m headed down the route of splitting everything into 256x256 chunks (thanks mtnhome3d!) but using meshes instead of terrains in light of Ross C’s comments (couldn’t agree more about your concerns regarding the quality of simulation by the way, I think I’ll be able to get more geological stuff later, along with building floor-plans… but even crude modelling will be better than the stuff we’ve got at the moment!) I’ve downloaded the T.ED demo, and hope to get going with JV-ODE once I’ve got the mesh side of things up and running (whenever that might be!)… thanks Happy Sammy. And thanks for the offer of help RifRaf.. I’ll send on my e-mail address now. Tim |
| ||
| Are your data points in grid form Like squared paper? Do you need vizualisation to be as accurate as the simulation itself? |
| ||
| Hi Andy, We're supplied it as a big text file of x,y,height values on each line (which do equate to a big grid), more file format info here! The vizualisation need not be as accurate as the simulation, but just to get going I was thinking trying to tackle vizualisation first, then moving on to simulation, whenever that might be! :) Many thanks Tim |
| ||
| Are you doing a proof of concept or will you be doing the actual app in Blitz3D? How well do you know Blitz3D? How much memory and what OS does the target PC have? What kind of simulation time are you looking for? |
| ||
| Hi Andy, This started life as a proof-of-concept thing, with a view of pulling together a few demos together to generate some video frames to accompany other projects we have underway. But the more I see of the work that goes on in these forums, the more ideas we have and moving to a real-time, game-like interface seemed a much cooler way to go! I think we’ll tackle it bit-by-bit though, based on the feedback so far I’m thinking of concentrating on a “Command and Conquer” style for the visualisation (with quite a limited zoom-out ability to keep things feasible) running a mesh-based terrain. Then onto (somehow?!) streaming the building data…:) Then throwing some physics/simulation at it once things are taking shape… This as a project is currently “off the books”, I’m coming at it very much as an enthusiast at the moment, but if the POC goes well I might try and make things more official. As for my knowledge of Blitz3D… not much to be honest. I’ve got the rotating-cubes/plane/light embarrassment of a first program behind me now… and become pretty familiar with the commands available. I’ve got 10+ years of dull business programming to call upon (must be useful for something, surely?!), and I used Blitz Basic on the Amiga a fair bit… I’m hoping it’ll all come back ;) Target PC’s are our work machines, no real 3D graphic cards to speak of, but if things go well I’ll ask them to invest :)… Current kit is: HP Compaq NW8440 Intel Core Duo 2.16ghz, 3.37GB RAM Running Blitz3D V1.98 On: XP Service pack 2. The simulation stuff could be done “off line”… there wouldn’t be any problems (if needed) to “drop” your chemical at a certain point (along with quantity, and other parameters), then have a progress bar pop-up while things are calculated, then a new mesh could be overlaid (glowing radioactive yellow or something?!). Obviously instantaneous stuff would be cool, and the physics stuff mentioned above certainly looks interesting and a great first step, but perhaps real-time fluid simulation might be outside the scope of a proof-of-concept for Version 1.0! Kind regards Tim |
| ||
| The physx physics library can do fluid simulation, and the nice thing about using this engine would be that you can put a hardware acceleration card in and it speeds it up massively (and not too much cost either) |
| ||
| Ansys or COMSOL might be much more appropriate for your task of simulating reality. Realtime physics libraries will at best "only" be nearly ugly wrong but never anywhere near reality with real circumstances and complex data. |
| ||
| Neither B3D terrains, nor meshtiles are suited for your task. They are well suited for games, but not for simulation. Use just one mesh with several layers of LOD(starting with full LOD), and then rebuild the mesh at regular intervals when needed. This would enable you to render one mesh(at LOD 5 perhaps), but at the same do the actual simulation on a high fidelity model(at LOD 0 perhaps), visualising it on the less accurate model. In stead of storing the data in a single file, you could store each datapoint in a separate file, with height as well as all other data and references to the datapoints to the north, south, east and west. It would take much more nonvolatile memory, but would make it easier to expand the area of interest later. The aim is to make a system which will not be hampered by artificial boundries like the area that your fire brigade covers etc, while rendering it with various levels of LOD. I haven't done much fluid simulation, but I would probably simulate fluids by creating a number of particle emiters, emitting a large number of particles, and then model the path of the particles. |
| ||
| Hi all, Thanks for all of this again! I'll take a look at Ansys and COMSOL, it looks pretty in-depth from first impressions! Not sure we'll have the budget for some of that kit though! :( Andy... I was wondering how best way to structure the data, just to check I've got the right end of the stick though... if we had 7 million datapoints, do you envisage having a structure containing 7 million seperate files? I can see that being a pretty flexible set-up (which is what we're after), have you had good results with anything similar? Thanks again for all the feedback, itching to have a go now! Might be a little while until we're doing stuff like this though ;-) Blender fluid demo Many thanks, once again! Tim |
| ||
| ...and thanks boomboom... I spent quite a while looking at what people were doing with physx, it looks incredible, and if I read rightly, very cheap..! Tim |
| ||
| >if we had 7 million datapoints, do you envisage having a structure >containing 7 million seperate files? At second thought scratch that. I was working from the approach of a custom system I designed and programmed a while ago. It had significantly more datapoints, and used an array of large disks, and data footprint was of no importance as the size of the data would never change. the numbers are against this, as you are targetting an NTFS volume. It would be about 30 GB worth of data at 4096 bytes pr file, even though you are only using 5KB of each file. You are propably better off having all 78000000 datapoints in one file which should weigh in at around 810MB on disk and in memory, but you can still build the mesh on the fly. > I can see that being a pretty flexible set-up (which is what we're >after), have you had good results with anything similar? Well yes, but I really got ahead of myself when suggesting you use that approach. I made a one off program which had to deal with a very large set of datapoints for visualisation mainly, but some processing was required depending on the data and the visualisation. It was written in B3D and would load the data seamlessly when needed and rebuild the mesh when it ran out of datapoints in memory. |
| ||
| putting your datafile on one of these drives with a gig of ram would double the speed of reading the file. http://techreport.com/articles.x/9312/1 |
   |