I like the look and feel of the new heightfield editor tool Aaron- bravo! I'm hoping to have a fiddle over the next few days. Is that a level of detail implementation?
It's very responsive here (well it should be!).
monks
L3DT Professional Release 2.5
23 posts
• Page 2 of 2 • 1, 2
I like the look and feel of the new heightfield editor tool Aaron- bravo! I'm hoping to have a fiddle over the next few days. Is that a level of detail implementation?
It's very responsive here (well it should be!). monks
Hi Monks,
Yes, it's a ROAM implementation (Realtime Optimally Adaptive Mesh), based on this simple example by Bryan Turner (login required), but modified for floating point data, view-based patch culling, and modified distance metrics, variance calculations, etc. At this stage it doesn't have particuly stellar frame rates (it's much worse than L3DTVi2), but my main interest is in providing a renderer/editor that's 'good enough' and works in all cases (L3DTVi2 did not). Anyway, I'm sure I'll be able to improve the performance as do some more tinkering, and read more of the red book (I just bought my copy). Cheers, Aaron.
Nice, I used to frequent Gamasutra a lot. Yea it makes a lot of sense imo to have a lod approach- especially as large terrains and procedurals take over more and more.
Hehe- the Red Book will be awesome reading I bet- for a coder anyway. I remember wading through some of 'Computer Graohics': Foley, et al- it's a *very* cool subject, if a little taxing on the grey matter. ![]() monks
Aaron, I think you should provide the 3D view but with DM pixels. It sounds slightly unorthodox, but this would make Design Mode a really powerful tool in my opinion. It would be using the same concept as Wilbur's Tessellation which I think is a very good thing. For starters, think of the sheer size of the maps you could operate on- basically this would give you a good platform to create continents but with a decent amount of 3D visualisation/interaction- something no other program has to my knowledge. The Raise and Lower Brush would behave just the same. You could even extend the roam algo to it.
I would see it visualised as 3D building blocks. You might even provide a very basic interpolation algo (or the option to toggle it)- that would make it very similar to Wilbur's Tess but different enough. You could ultimately go between 3D DM mode and 3D heightfield modfe- maybe rough out a large area in 3D DM, then with a selection tool, take that area into higher detail in the 3D heightfield editor. It would no doubt need some mem mangement. I'd also love to see contours as both a tool and perhaps as s shader in 3D mode. Just some thoughts ![]() monks
Hi Monks,
There are a couple of ways I can get the design map rendering in the 3D viewer/editor, and some are quite easy to implement. However (and you knew there would be a 'however'), my preferred option is a more radical change - I plan to split the design map into two; a 'pure' heightfield and a mask map. Currently, both data types are mixed in the one map, which means some algorithms have to be written (and maintained) for both the heightfield type and the design map type. By splitting the map into two, we can then reuse all heightfield algorithms on the height component of the design map, including the use of the 3D renderer/editor. This will also allow plugin developers and script writers to do more fancy things with the design map by reusing the available heightfield effect functions. In fact, I may go further and split the mask component of the design map into separate maps. For example, there would be a peak mask map, fractal mask, cliffs mask, etc. While it was convenient in the past to bung all this data together into the design map, this is no longer the case - my recent changes to allow user-defined map layers have, as a side effect, made it just as easy to have a 'height design' map and a bunch of mask maps than it was to have just one design map. Doing all this will also give me a good reason to re-do the design map display schemes system, which has, I think, outlived its usefulness. The new system would probably allow users to overlay up to three mask layers on the 'height design' map (looking for a good name!) as RGB colour overlays. This would work in both the 2D and 3D renderers. The image drape can also be extended to the 3D view, as Rummy requested in another thread recently. I'm in two minds as to whether I should include all this in in L3DT v2.5a next, or hold-off for 2.5b. The critical feature for L3DT v2.5a is a bugfix for GarageGames' Atlas plugin - if that happens soon, then these grand plans will be deferred, but if it takes longer (and I'm not strangled by disgruntled 'L3DT for Torque' users in the mean-time, perhaps justifiably) then I may as well move this into v2.5a. Anyhoo, I should stop my ranting about architectural changes and start programming (well, after dinner maybe). Cheers, Aaron.
Yes, great idea. I think getting the DM as a 3D map would double it'seffectiveness. And you have there the makings of implementing a good workable solution for this whole big terrain problem (which won't go away!). That is, the best way to approach it imo (as I'm sure you know by now....) is to break it down into stages: DM -> HM. Well, that's what you've always done with L3DT. Add to both those stages the lod rendering and you have a doubly capable workflow.Hmm. ![]()
Absolutely agree. Masks- this is huge area. ![]() beach', etc. Then you can easily take these into your final renderer (game or whatever) and breathe life into the heightmap with your textures/models. Until then, a heightmap is really just a sea of points. I think this is L3DT's primary strength. L3DT has the beginnings of a 'deterministic' link between terrain model and (game) enviroment. The main properties you need to create this link are water and temperature; temperature being the more fundamental. I think Where you can take this depends on how well your maps are derived from your model, and also the model itself. Take water- most of L3DT's texture maps come as a direct consequence of having a water table(?). The output texture maps are meaningful because of the water table (and probably some extraction of info by yourself)). The closer you can tie the creation of the attribute maps to the whole process of procedurally creating the terrain- ie erosion/climate (water/temp)- the better the terrain will be- by 'terrain' I mean heightmap + all the other sundry things that inhabit that heightmap. OK, so improving a physics model has practical limits but even if your physics model is simplified you could still extract the parameters old skool (eg, low slope + proximity to water = mud).in order to define your output maps. Also, in the absence of an accurate description of model state, using GIS dem analysis methods after-the-fact is going to be equally useful (and probably a lot easier to code/run)- after all GIS data is derived from terrain afer-the-fact rather than directly from a sim of terrain creation. Basically I see this as a way to get GIS datasets for fantasy places/landscapes. The full benefits will be seen in the final game/renderer.
Sounds good. This has come up on another board: the role of renderers in terrain modellers. I think the main function of a terrain modeller renderer should be to visualise the effects of terrain + texture placement (ie selection masks) + textures so as to expedite the whole move from builder -> renderer. The more options you have for generating selections from the terrain and placing textures intelligently, the easier it will be. monks
Yes, of course. L3DT Professional comes with free upgrades for 18 months. Please consult your registration/purchase receipt e-mail for download instructions. Best regards, Aaron.
23 posts
• Page 2 of 2 • 1, 2
Who is onlineUsers browsing this forum: No registered users and 172 guests |