Leadwerks Engine LOD demo
Community Forums/Showcase/Leadwerks Engine LOD demo
| ||
| Use the .bat file to run the exe. Adjust the "Model Detail" setting to see the low-res models: http://www.leadwerks.com/files/LODTest.zip OpenAL is required: http://www.leadwerks.com/files/OpenALwEAX.exe  |
| ||
| Has anyone had a go on this yet? Come along - shake-a-leg people. |
| ||
| I don't mind. It will grow slowly, but I am doing this right from the ground up. I'm just putting out a few beta demos to showcase various features as I add them. |
| ||
| I feel another Counter-Strike coming on, or Half-Life style games off of this. |
| ||
| Curious - what kind of machine are you targetting that LOD is a viable technology? Most games don't bother anymore because it's ultimately faster to just throw triangles at the card than it is to try and figure out distances and LOD levels. Generally, performance levels out once you drop below 200 triangles or so (probably higher these days) so LOD models really won't be giving you much of a speed boost, especially with Half-Life style geometry. |
| ||
| I agree that in practice you don't really need to create low-res versions of a 256-poly model. I just used the barrel model for testing. You would probably only bother with a low-res model for models that are at least maybe 1500 triangles. LOD isn't just for rendering speed; It can speed up mesh collision and lightmapping as well. It's also nice to have a "Model detail" setting, which just chooses a lower-res LOD model. Probably my main reason for implementing this is so that future versions of the editor will be able to calculate lightmapping faster, since they can use the low-res models to cast shadows. |
| ||
| Collision speed is a viable use for sure. One thing you might want to consider with your engine is allowing low res version of meshes to be used for collision detection regardless of which detail level is being drawn. We do that in Unreal and it works really well. |
| ||
| Yep, I already did that. There's an option to "Show hitboxes" in the control panel. To access the control panel, just right-click to release the mouselook, and you can move the mouse around and adjust the settings. Hitboxes are used for large object collisions, things that don't really collide per triangle, like players. You can make a model's hitbox out of brushes in the editor, and just save it in the same folder with the same name, plus the suffix "_hit". Each model also has a bounding box calculated around it, which by definition encompasses the entire model. Whenever per-triangle collision is used, like for visibility tests, a test is first run on the bounding box. If the box test fails, the model is dismissed. I think the most interesting and significant aspect I have encountered with this engine is all the flagged update states. If an object moves, several variables are set to show certain states changed. Each object then has a build() routine, which updates only the states that show they have been changed. The build() routine only gets called when those states have to be accurate. It's like saying "Make sure everything is up to date because I am going to need certain values". For instance, if the object moves or rotates, a variable "matrixchanged" is set to "True". Now let's say I call a transformation routine involving this object. The build() method is called, which detects that the matrix is changed, which then rebuilds the matrix and sets the variable "matrixchanged" to "false". I might position and rotate the object ten times before calling a build() routine, and the matrix only gets rebuilt once. The build() method usually occurs at the beginning of a basic math or transformation routine, so I don't ever have to call it in my main code. In fact, the build() routine might get called several times in a stack of functions, but it only updates when something has changed. I use these state changes for object bounding boxes, global positions, and even lighting changes. I actually have an object type that stores data for one light and one entity's interaction. Both the entity and light link to this structure. If either the entity or light move or change in any way, the lightlink object gets set to a changed state. The next time the entity is drawn, the change is detected, and the light's affect on the entity is re-evaluated. Does the light have a clear line of sight to the entity? What is the falloff of the light and it's distance from the entity? The lightlink object is then set to a nonchanged state, and is again "dormant". The results is very efficient; certain calculations only get performed when a state change has occured, and they only get performed when accurate data is needed. If nothing is moving, very little processing occurs. If something moves, it gets updated once and reset to a "nonchanged" state. |
| ||
| Yeah I had a go today and it looks fab. Setting the vertical sync makes it look soooo smooth its wicked! I have 3dws and the engine and I am trying to understand the hows and whys and where fores so I can put a small map together utilising as many features as possible to see what a level could look like. IPete2. |
| ||
| Nice demo Josh, this is Blitzmax right? I believe Blitz3D uses a similar flagged update system (for some things at least). Warren: F.E.A.R Combat wouldn't be as playable on my PC if it didn't have options to reduce detail levels. The same applies for my neighbour. It does matter :) It's down to the cost of high end GFX cards. You're average Joe (me included) can't justify spending £300 every few months. |
| ||
| Warren: F.E.A.R Combat wouldn't be as playable on my PC if it didn't have options to reduce detail levels. The same applies for my neighbour. It does matter :) Well, that's not quantifiable without knowing what "reduce detail levels" means in FEAR. Is it actually using lower polygon models or is it doing something else? Lower screen res, lower res textures, less geometry entirely, etc? |
| ||
| If I remember right, it caters for both character detail and a smart mode where it removes non-essential geometry/entitys when performance drops. There's a features you should add Josh ^ |
| ||
| Just tried it and it's really rather nice. I got 30 fps no problem with everything on, and it just started to chug on 8X AA and 4X anis. but 4X for both was just fine with everything else maxed. This on a 1.8a P4 with one gig and a £29 FX5500 dabsvalue own brand card! Not bad frankly, not bad at all! ;O) I'll maybe try it on the main machine at some point too. I'd like to try some of my own models in it myself, but I don't know if I can have an artwork path to this sadly. Now if it eat directX or maybe somethng widely in use in the 3d world... I'd have to guess it may use a format more widely used in the 3d games world, but I know it not! I got LW and DeepEx, but I don't think it stretches quite this far, regrettably. Nice work. |
| ||
| It's really disappointing that you couldn't get your real-time shadows working as you'd hoped. I've been following your topics about the engine since you started, and now you're talking about using LOD to aid in lightmapping? Bah, that really sucks. It's obvious that you're shooting for realism here. I just wish you'd ditch relying on lightmaps and try to get your stencil shadows worked out. Light & shadow should be dynamic. |
| ||
| post*2.0 |
| ||
| I actually did complete my stencil shadow routine. I decided against using it, because current hardware cannot handle it well. I had to choose between an engine with stencil shadows that could only handle tiny corridors, and an engine with projected shadows that can handle huge areas. I decided to go with the latter. I think it's more widely useful, and the graphics look better. |
| ||
| Yep, stencils are problematic... CSM would be the best choice today for shadows, but I too think that even projected shadows are better than stencils in most cases. Still haven't tried your demo though 'cause I'm on my laptop now. |
| ||
| The word Dynamic is mispelled in "Dyanamic Shadows". Looks like you finally got some very accurate mouselook code too. Also, the wire frame mode isn't really true wireframe. It's not showing all wires. So I guess it's "pseudo-wireframe"! It has to be blitzmax because well...we know it's not Blitz3d and Josh isn't the C++ type. |
| ||
| Actually, it is showing all the lines. You're thinking in terms of triangle meshes, which BSP solids are not. |
| ||
| A quad is composed of two triangles. Wireframe would show the distinct 2 triangles that make up the quad. Some apps have a wireframe mode that outlines the outer perimeter of a series of triangles where all the vertices are on the same axis. |
| ||
| hehe :) |
| ||
| Nice demo. I did notice that if I look at the top of one of the barrels I can see pixellation from very steep angles. |
   |