Flexman
-
Posts
916 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Flexman
-
-
im used to generate the cone map from the heigthmap then tweak the cone map manualy like adding a little of gaussian blur to remove artifacts and minor modifications...
Sorry to be a pain, but what is the process of generating the heightmap from the diffuse?
Is it a greyscale? 0 to 255? Could you provide the original heightmap you used as a reference? I'm trying to create my own and getting odd results.
-
What makes good source files for HeightProc.exe? I takes a straight heightmap. What settings did you use for the test scene above?
-
Merci. It will take me a while to look at this and check it out but I think this might work well for the rocky/gravel boundary around areas of airstrips. Certainly can't wait to try it on the interior of our Chinook helicopter which has lots of quilted padding, that should suit this shader quite well.
-
Indeed. The flying around tables and chairs is a good analogy for what flying is like in Battlefield 3. In Leadwerks as you move past the 20,000 unit mark those rounding errors start to creep into the shadows causing jitters. That's different from the camera range but if you're not going to have a long distance to the horizon then you keep the precision.
OH I must say, I fell in LOVE with EGGplanes, cute versions of F14s and A10s shaped like eggs. That would be a great little game to knock out if you had a small army of artists.
-
Aha, that makes perfect sense now. Yes an index of some kind would be of great help.
-
Problem with adjusting scale universally is that you just end up moving the decimal point but the precision problems remain. Say you reduce it by a factor of 10, your near camera object, say you're on the runway, runway markings which might be 1m away, are now 10cm away in real-world and game units. In Leadwerks there's a slight problem, load up the editor, turn on debug physics mode, add an object to a scene and then scale it. Have a look at what happens. *spoiler* the physics shape doesn't scale - oh my */spoiler*
The Virtual Earth book I linked to in my earlier post has some downloadable programs which let you explore this very thing, by adjusting parameters, scale, zbuffer and double/float precision, you can see the results on an actual globe. And it's not always intuitive and often not pretty.
I might have had some experience. If you want to buy Empire Interactive's Enemy Engaged Apache Havoc or Comanche vs Hokum, they are available from Good Old Games. There's a little bit of me in those. I also worked at Microprose UK for a while and wrote mission tools for Janes Longbow 2 Apache helicopter simulator.
Frednaar is working with me on the physics modelling on the Apache in Combat-Helo using his own blade element theory flight model aka HTR or Helicopter Total Realism which is a free Microsoft FSX add-on that replaces the Microsoft flight model with something much more realistic. It's available in the forums at Hovercontrol.com
I got a plug in there for you Fred
About exported meshes. If you try and use a 3D modelling program to take a DEM and turn it into a gridded hightmap mesh, it won't work. As you suggest, performance will be TERRIBLE. Detail is a problem. Actually let me re-phrase that. Detail IS THE problem. It's worth assessing just how much you need for your particular game. Irregular triangle meshes are they way to go if you're going with terrain slices, large flat areas can be covered in just a few triangles with mountain tops having more detail. A tool like Grome (I'm really NOT a salesman for them, just citing recent experience) t exports these kinds of meshes. EEAH (Enemy Engage Apache Havoc) used this kind of irregular triangle mesh terrain. Also the terrain slice meshes will have to be loaded "on the fly" as you move around unless your world is small enough to pre-load them. This potentially will cause stuttering or pausing unless it's done on another thread. Then you have the problem of textures on these slices. If your game is fine with 1024 textures covering a terrain tiles you can add noise layers or even throw in some instanced objects to add clutter.
If you want to go the way of generating your terrain geometry at run-time then the technique use in FSX is solid. FSX built the terrain vertex buffers over several frames, and it was double buffered so the next terrain was being assembled while using the current one is being used.
-
He's an evil genius.
I hadn't heard of Cone Step Mapping but it sounds cool and looks great.
-
LE or any other off-the shelf engine isn't suited for a jetsim but not impossible.
Grome is an editor, not an engine (although they do license the engine used in the editor). Our use of Grome is about assessing how we can use LE to scale a game up to 100x100km. It's sole purpose is to take large world terrains and slice them up into single meshes, these meshes would be used in place of the built in Terrain object (the LE Terrain object can only have one instance and is not moveable). The down side is that you also have to dump the awesome performance friendly vegetation system. But you shouldn't need it for a jet sim.
LE is about as capable as any other engine in this regard. You can look and look and never find anything ready to roll your own sim. A jet game maybe. Lots of games with fighter aircraft cheat like crazy, using perspective and scaling tricks. They give you the impression they are flying at 500 kts but if you measure how much terrain they cover per second you'll realised they are moving slowly compared to a real jet fighter. Video games are all smoke and mirrors. Apache Air Assault had bushes the size of houses. Look at the fighters in Battlefield 3 videos, they are pulling turns at indicated speeds that would take miles in real life.
My project doesn't need more than the maximum terrain sizes allow so the only issue has been how to deal with the precision and z-buffer problems that do occur and you have eluded to. Z Buffers are the weakest link, so long as you keep camera near and far distance in a range that's retains precision you solve a lot of z fighting problems. But if you want a visible horizon out to 6 or 8km then your camera near distance needs to be 6m. Which is terrible if you're sat in a vehicle, most of it would vanish. To workaround that you have a couple of tricks,
First, you adjust the camera range dynamically, the close to the ground you are the nearer the horizon appears. And the near camera distance can be inches away.
Second, your vehicle is not part of the outside world, it's a portalised object. this is what I do in my helicopter game.
Let me elaborate on how we do the portalised vehicles, I don't want to put you off, it's not as bad as it sounds, no matter what engine you run with, you need to get your hands dirty. Our vehicle interiors are 3D meshes separate from the exterior. The cockpit interiors are positioned at the origin in their own world; the render cycle first updates the outside world, then we do some frame buffer copying to a cockpit buffer. There's a lot of fiddly code to match up lights, camera and movement (action?). The final composite is an illusion but near perfect. This is how it's done in most simulations. This delivers a rock solid cockpit interior free from precision and z-buffer issues, plus environment objects such as trees, water, rain, particles, can never intrude into the vehicle space.
The way we did it was highly technical from the art aspect, you can't see the join, even use TrackIR to lean out of the cockpit when the doors are open. Getting all that to work was specific to the kind of game we were making. But it can be done (and is done) in other engines.
If you're studying technologies for the purposes of simulation games you'll have come across Outerra which is the poster-child of how far you can take GPU and procedural content generation. Many of the techniques used are starting to find a foothold in other applications now. For example logarithmic depth buffers are used in Google Earth and it wouldn't surprise me to see a Unity mod for that.
Other techniques for rendering long camera distances include multi-frustrum rendering (example: Infinity The Quest for Earth) which I have tried in Leadwerks but the cascaded shadow maps were a disaster, I couldn't get them to match up at all but just because I couldn't get it to work but that doesn't mean it's not possible, my patience just ran out and some swear words were used.
So far the best option for large terrains using Leadwerks engine would be the treadmill approach. This is something I'm considering for Leadwerks 3D when it's released. So long as streaming mesh data in is supported, this should be
One final word, simulations use two co-ordinate systems (sometimes 3), your real world co-ordinates, and your interior 3D engine co-ordinates.
You might find this link interesting, it's a White Paper on Microsoft's Terrain Technology. I would recommend looking through it. Even if you have no intention of developing ellipsoidal worlds many of the techniques I've mentioned are covered.
-
I'm really pleased to found something that works.
Although the best sub-sim I remember playing used a waterfall display, don't think you got to ever see the sub exterior. SSN-21 Seawolf?
-
Best way was/is camera relative rendering, all objects are transformed around the origin. Ogre3D has such a mode (with problems at time of writing). This is not possible with Leadwerks Engine for the reasons I'll go into.
Another technique is tread-milling. Microsoft Flight Simulator uses this technique, your position is reset as you cross the border of a terrain tile. This can be emulated at one level in Unity and Leadwerks by parenting objects to a tile-object and moving those tiles around the camera. In Leadwerks although you can't use the terrain or vegetation system with this technique so you need to build or load in your own terrain geometry.
There's a book just been published which explores all these concepts 3D Engine Design for Virtual Globes now available in electronic format. It touches on precision and z-buffer antics.
There's no magic bullet for precision, doubles instead of floats will get you a bit further but you need to be a bit radical. A lot of these off-the shelf 3D engines don't do radical well, they are so interconnected with physics, shaders and lighting.
Quadtree software produce a terrain editor called Grome that's well suited to editing huge terrains and exporting individual tiles (they call zones) and has been used for numerous console flying games (e.g. Ubisoft's Blazing Angels). I'm experimenting with this one. The main problem is the pipeline from Grome to Leadwerks and poor threading (just because you can do it in language X doesn't make it good).
I could write buckets on old simulations, some never did anything so fancy as the above. A lot didn't use heightmaps in the way they are often employed today as they pre-dated the hardware that heightmaps are optimised for. Constructing geometry on the fly from a dataset was the order of the day.
-
Before I filed a bug report I thought I'd post here.
First...
Vegetation LOD ranges
^^= View distance to...
Currently, vegetation model LOD works by multiplying the editor Vegetation LOD distance * model LOD number.
In the editor Vegetation settings: If you specify LOD distance = 100
And you have a tree model with 5 LOD models, this results in the following:
- vegetation_trees_oak_a.gmf ^^= 100
- vegetation_trees_oak_aLOD1.gmf ^^=200
- vegetation_trees_oak_aLOD2.gmf ^^=300
- vegetation_trees_oak_aLOD3.gmf ^^=400
- vegetation_trees_oak_aLOD4.gmf ^^=500
Which isn't a fine enough level of control for tuning. Especially if you only have 2 LOD models or very small ones.
Ideally a command to set the LOD would be better, like thus...
veglayer1.setLODdistance(lod0, 50)Billboard Normals
These are reversed? Here are two screenshots, one is the same position but rotated about 180' to look in the opposite direction. Look in the distance (not the trees close to the camera but the middle distance where they transition from 3D to billboards).
Screenshot A - 3D tree model is dark facing us. Billboards in the middle distance are lighter in colour.
Screenshot B - 3D tree model is light facing us. Billboards in the middle distance are darker in colour.
This makes blending near impossible for all lighting conditions.
Collisions FIXED
If I setting this to 5 in the editor then collisions are not recorded for some reason in code despite using the following code:
Collisions(5, 1, True) ; Collisions(1, 5, True) ;
Leave them at the default value and collisions work. It makes detecting collisions with different vegetation layers difficult.
Macklebee sorted this one out. I had to edit COLLISION.LUA and COLLISION_CONST.LUA to set the values.
Raycasting on vegetation returns type "1" every time regardless of the vegetation collision type. This can be a problem.
Cabbage Patch Billboards
An option to turn off the overhead billboards. This would eliminate the presence of cabbage patch doughnuts appearing when viewing at altitude. Presently the only workaround is to edit the billboard to cut and past over it with a flat image which doesn't work too well.
BIG FEATURE REQUEST
Which I suspect can't be done but would be a big help certainly in making our game a bit more polished:
Fade-in vegetation billboards rather than a snap transition.
- vegetation_trees_oak_a.gmf ^^= 100
-
-
-
Check out some videos of what can be done with the engine.
I think, regardless of the engine you will run into performance problems but Leadwerks is pretty good at culling, especially when it comes to vegetation.
The other issue you might have when coming to Leadwerks is the art asset pipeline. I highly recommend you create documents covering what works for you. I have no doubt that you can put together a high performance racing game together with Leadwerks. But because of the deferred rendering nature the things that one might consider easy can be quite problematic, such as Transparency.
Heaven help you if you want to make a submarine game though
Physics, audio, a high performance veg system and a range of language choices. As the above poster said, Ogre is just a renderer, you'll need to do a lot of work before you even get to start on a game.
-
That's really useful. I made a very simple one for debugging but yours is much much better. Is it easy to create a new instance and stack them?
-
When you get to version 3.142 you can call it LeadwerksPI
( PI not like Magnum PI )
-
The particles rotate so you can't get away with simply using the texture co-ordinatess unless you unrotate the the 'uv' to compensate. If one did I'm guessing that might work.
-
I was having a quick play in particles.vert and particles.frag trying to tweak it so it graduate the diffuse intensity from top to bottom of an individual particle. The aim is to fudge some shaded smoke effects.
Any ideas to do this in particles.frag? Graduated shade from top to bottom? Sphere shaded particles as simple as this would work well...
-
I love seeing stuff like this.
Good work. A*
(little pun there) -
Your robots remind me of the TESCO supermarkets invasion of Denmark thanks to this video...
-
No I can't, unless I fix the bug in the engine. Right now joint:SetStiffness(1000.0) has no effect, also not -100, 0, 1, 2, 10, or any value. The joint keeps rotating at the same speed as a joint without stiffness settings, and it also stretches the joint by exactly the same amount when doing a body:AddTorque(Vec3(500,0,0)) to make it rotate so fast that the joint streches.I looked at the source, and the whole NewtonJointSetStiffness is commented out, but it's not commented out for NewtonJointGetStiffness. Maybe I can just uncomment it, to fix the bug.
You know. That might be why I had one hell of a problem trying to get landing gear articulating correctly. I spent a week trying different approaches :/
Somewhat frustrating.
-
Just add blend=alpha as Metatron posted and try it. If still no joy add an alpha layer to the texture. It shouldn't be difficult to do.
Your setting of the alpha in code should work as you intend (it's multiplying that value with another). You should be able to control fade in and out by adjusting the alpha in SetColor() once you get the texture and blend sorted out.
-
MESH.FRAG takes the alpha of the model, so you've set it to 0.3 and later if you have LW_DIFFUSE defined it multiplies diffuse with the texture values. So possibly it's worth checking the models alpha channel and if it's pulling out a ZERO it's probably that.
Materials are well worth checking here as your function (above) looks fine to me.
-
I'm genuinely excited to see this running. It's brilliant.
One of the things I do to explore game rules is turn it into bits of paper and dry run it at a table, really scrappy rips with scribbles. One of the Harry Potter games had it's mechanics tested using cardboard, pencils and blu-tac, much cheaper the prototyping code and the sort of thing you can do it in an afternoon, beer garden optional.
Terrain in old flightsims
in General Discussion
Posted
Yeah, once you sort out the details of your co-ordinate system (game world <> engineXYZ) you can start to work on the treadmill. @Mike I didn't know that's what you'd done, cool to hear you got it working OK.
One caveats using tiled terrain meshes; automatic occlusion/culling. Make tiles too big and you'll loose the benefit of object culling, to small and you have a lot more tiles. Finding a size that works for all altitudes might be tricky. But over the sea it should be fine, you eliminate a lot of issues there. Make something flexible so it's easy to adjust the tile size in case you have to workaround culling/performance issues later.
- Rich