Flexman

Leadwerks engine has a number of built-in uniforms to pass values into shaders. I propose adding a couple of extra uniforms for developer use to pass game values into shaders more easily. Rather than having to scan *all* loaded materials to pass uniforms to them (not trivial as there isn't a publicly accessible list of loaded materials or shaders) it would be very handy to have a few UserData uniforms, much like entities have UserData keys. Only a few would be needed and can't add much more overhead than the existing Leadwerks uniforms. userDataVec4 userDataVec3 userDataVec2 userDataFloat userDataInt

I was going to use MaterialDrawCallback() to bind user skins for different vehicles. This callback is supposed to return a pointer to the entity being rendered no? Any attempt to access TEntity properties results in an exception even though it's not a null pointer. Not really sure what's going on with that. Function MaterialCallback(material:TMaterial, entity:TEntity) if (entity.material) // kablewie endif End Function Just wondered if anyone else has tried this and got it to work OK? Seemed like a reasonable way to create non-instanced player skins.

Thanks, that's working beautifully now. The ATI workaround drew my attention.

This is a GL 3.0 extension so I'm not too sure if I should be using it. I need to cut'n'paste a small section of one buffer into another and not clear on what best practice is here. I'm using glBlitFramebufferEXT which does the job fine. An example... glBindFramebufferEXT(GL_READ_FRAMEBUFFER_EXT, Self.buffer.framebuffer) ; glBindFramebufferEXT(GL_DRAW_FRAMEBUFFER_EXT, 0) ; glBlitFramebufferEXT(0, 0, 511, 511, 0, game.scene.screenheight - 511, 511, game.scene.screenheight, GL_COLOR_BUFFER_BIT, GL_NEAREST) ; glBindFramebufferEXT(GL_READ_FRAMEBUFFER_EXT, 0) ; glBindFramebufferEXT(GL_DRAW_FRAMEBUFFER_EXT, 0) ; But since Leadwerks minimum requirement is Shader Model 3, it's reasonable to use this no? Anyone have an alternative to consider? All I want to do is snip out a small region of the main buffer for use in a texture which I'll post process for night vision. Currently I'm using a second camera to do this but it seems like overkill and can cripple performance.

That's an interesting one. I'm not sure how you'd get input from a Midi device unless you can program it to send keystrokes that could read in your LUA script. Only program I know of that can turn MIDI keys to keystrokes is MIDI2KEY written to play music inside the Lord of the Rings Online game. A link to the source is here... Lotro Forum Link - MIDI2KEY

Ahhh, ok interesting. Cheers.

Would it? I thought geometry of the building would mask it if it was? Are they not depth tested if you specify that in the material, it must be because I have a huge corona that acts as a short flash and is correctly masked in the scene by trees, objects etc. unless the exact centre is behind something. As it is, it almost works perfectly for what I needed. Maybe I don't quite fully appreciate how they work, they do have a neat auto-fade so they don't blink, nice touch that. Perhaps what I really need is just a straight billboard with alpha. As a programmer I would like the option of having it show through a house or not via EntityOcclusionMode() but technically Coronas are not true entities. Is it just a bounding box test?

Is it possible to disable culling for coronas? I used to have coronas position at or near lights that are often near other entities. For explosions I can't position them at the point of the explosion as the vehicle I'm destroying occludes it, same goes for the emitter in the transparency world. A workaround is to 'lift' the flash over the vehicle, since it only lasts a few frames you don't notice.

Well, if using DrawRect() all you have to do is Bind() a texture before hand and DrawRect() paints your texture instead of a plain colour value. So there's plenty of scope for using plain drawing functions as described by an XML file with textures if you want to do that. I have a hard time with all the event stuff that has to go with it. Actually it's so bad I want to stop thinking about it now and go out into the sunshine and try and fix the car.

LMAO at Lums idea of Microsoft servers verifying each pixel over the internet. I needed a good chuckle. Procedural functions are more or less the way I decided to do GUI elements but I hadn't considered 'glass' buttons by using vert colours. That's OpenGL 101 and used to really good effect.

As a matter of personal curiosity, how does Windows XP or 7 draw it's GUI? Is that all images or done mostly in software?

GROME is a commercial editor built for creating large terrains and slicing them up for export. It's been used in a number of high profile games. You would have to do everything in the GROME editor though and it's a bit of a leap going from one to the other. Blender may do this also? Another important consideration if you're going to make a large environment is the dreaded 'jiggle' which comes with math errors associated with moving large distances from the scene origin (typically 20,000 units+) this results in shadows and geometry jiggling around when the camera matrix is updated. So depending on how big your world needs to be you might need to build your game around a "treadmill", resetting the scene origin seamlessly as you move through the world. Or render the scene in layers to maintain camera and z buffer precision. Lumoojas streaming idea would make this practical. It's not a trival exercise but not impractical either. Many MMOs and simulations do this. So far it's not been done in Leadwerks, as far as I know. Maybe someone has an example already?

Just to add my 0.00000002$ (inflation even makes opinions worthless these days) that UDK modded water is just a prop in a scene and built as such. It is exactly what it needs to be. What sells that ocean is the island and the sound. It's perfectly fine for that and I wouldn't laugh at it. You can over egg a pudding. Red Ocktober is making a sub game so his needs are probably more than such a simple implementation would deliver. I suspect he would be better off with some kind of fluid simulation if it were available. Curiously I don't see many projects needing fluid simulation, if anything, the UDK implementation would be more than suitable to sell a scene for most FPS projects unless the goal is to bog down gamers computers with so much mathematically assisted visual **** they don't need. It really depends what to goal is here. Is it a technical exercise? Is it making games? Or just getting the job done? Maybe water sports games where you drag an invisible sphere through the water surface and it creates a suitable wake, I've seen it done using normals in the World of Warcraft Cataclysm expansion to great effect. I don't have any answers. I currently have no use for water beyond a small lake or river which doesn't need any of this but might for a future Search and Rescue simulation game. It would be nice to have a decent off the shelf (store) module for a ocean effect that Red Ocktober could use as he's been wanting one for so long. If the store had a ground fog height shader I'd buy it. @Dozz Cheers man, awesome

I looked at the shaders and scratch my head for a bit then realised something I hadn't tried. Normals. By adding LW_FULLBRIGHT to fix the normal on the glass plate that covers the screen it fixes the glare (and another issue relating to camera angle and the video underlay). Here's the final mesh_cubemap_glass.frag shader header. #define LW_DIFFUSE texture0 #define LW_CUBEMAP texture1 #define LW_FULLBRIGHT Include "mesh.frag" And the material file... texture0="abstract::apache_pit_mpd_glass_skin.dds" blend=1 depthmask=0 depthtest=1 overlay=0 zsort=1 cullface=1 castshadows=0 specular=13.50000000 gloss=0.10000000 shader="abstract::mesh_diffuse.vert","abstract::mesh_cubemap_glass.frag" It does the job preventing the night lighting from obscuring the screen and it retains the cubemap reflection. So all in all quite pleased, I learned a bit more about emission and specular channels too. That might be really handy when it comes to do the infra-red night vision stuff.

I thought you might have had an evil genius idea to make it practical. But it's no bad thing, one less thing to go wrong in a game. Thanks for the response.

Once in a while you want to do something exotic which bends the rules slightly. Is there a material setting that will exclude an object from a lighting pass? What I want to do is have the MFD material that is the screen area not be subject to the green pointlight above it. There's a 'glass' layer over the screen that shows the green point light when the layer behind the glass is showing a bright image. These attached images show the green light reflecting when the video underlay is both active and switched off. If I hide the faux glass cover it's fine.

SQLlite has an R*Tree module for optimised spatial queries (http://www.sqlite.org/rtree.html ) which would be nice to have. It would certainly add a lot more possibilities to making games with LE. All the issues you mention and more are ones I've had to resolve and find work-arounds for. I don't have time to make an editor so what I was thinking to save time was adding an 'in-game' paintbox to stick objects (dynamic veg and ground clutter) into the database.

Whatever works for compound entities without blowing apart. Will investigate.

Oh my, that makes sense. I'm going to try this myself. Typically I'm only freeing entities that are in view. Little edit.. I take it then that the entity reference being freed is perhaps not the top level parent? TModel being the container for all the LOD meshes and body. I just checked my code to confirm I'm Freeing the top level TModel, regardless of it being within the view volume with LOD1 visible (my M1A1 tank model has LOD0, LOD1, LOD2, LOD3). So I can't easily replicate this quickly. My TModel reference comes from calling GetMeshModel() with a pick result, this ALWAYS goes to the top of the model hierarchy. ' DO SOME PICK HERE THEN FETCH THE TMODEL ENTITY ' ' AFTER CHECKING FOR NULLS ALWAYS ' Local model:TEntity = GetMeshModel(hitpick.entity) Function GetMeshModel:TEntity(entity:TEntity) Local cName:String While entity cName = GetEntityKey(entity, "class") If cName = "Model" Return entity End If If entity.parent Then entity = GetParent(entity) Else Return Null End If Wend End Function

Try setting the pointers to NULL after freeing them and then force a garbage collection (GarbageCollect()??) If you have a console window open so you can observe resources coming and going you might observe that the process of freeing up testures/sounds is not instant. Is it possible you might have a situation where a reference count is incorrect and so the garbage collector isn't dumping like it should? I know FreeEntity() works as I expect it to with 2.42 but I don't do anything too fancy with LODS and models. When I used FreeEntity() on vehicles I want removed from the game world they do vanish. Although the textures can take a few seconds or longer to announce they have been removed from the system.

Coronas stopped appearing in the background world. The shaders they use haven't changed so it's likely a change in the engine. And culling can be an issue too. I only just noticed that one last night. Avoid parenting them to objects in different worlds (or at all if you can avoid it). Why is it needed to parent them to light sources now? They are handy for other uses.

This is a longshot and probably will end up in feature requests. Leadwerks 2.4+ added collideable vegetation and picks that work against them too. Great stuff. But suppose I wanted to destroy one of these trees, say through a collision...or fire as per the screenshot below. Is there a practical way of doing a pick or a collision test to get at that entity data to remove it? It would be handy to get at the internal array entry for the tree from pick information.

I don't want to hijack the thread but shell casing ejection is not overkill. It's a feature observed by crews and night vision footage of engagements, clearly visible from other helicopters and certainly visible in external views particually the gun camera view in which they fly past. They are recycled much faster than bullets since they don't persist in the viewport very long, typically only 15 bodies are required (at altitude they have fallen away, on the ground they form a small pile that remains a consistent size). A hand-held gun would benefit just the same, having shells bounce around your feet with audio FX would be a nice touch. So easy to add a body that is thrown out of the chamber position. Throw in a user setting for debris or small detail objects to set the number you want live for each player.

That's pretty much what we did for the 30mm cannon on our helicopter. It does have a high rate of fire (one round every 96ms). With the new veg collision system I would see enormous FPS hits when opening fire, but the weird thing was that the terrain size of the map had a *huge* impact. Switching from a 2048 to 4096 sized map made a huge difference (bigger = faster) so there's some performance oddities with various map dimensions (regardless of tilesize). Picks can cause micro-stutter when it has to generate a collision shape for the first time too. Josh said he plans to change this to generate them at load time. For each shot fired from our Apache, a shell casing is spawned as a newton body, on the whole lots of newton bodies are hungrier than raycasts in our game (take out the raycasts and remove the casing limit and at around 50 shells the system begins to bog down). A limit of 15 body casings and 50 active raycast has far far less impact on our production map. It sort of depends how many you might have active at once and size of arena. Just offering experience of what I tried. *edit* I added a random off-axis value to the bullet spawn vector to generate some spread, I used the ammo count as a random seed since this should be consistent across a network game? Looking for better suggestions on how to do this.

I found this function I used to pass a position and a sample height height that returns the terrain height as well as any mesh object above it. ' RETURNS Y AS GROUNDHEIGHT ' Function GetPointOnGround:TVec3(pos:TVec3 var, pickheight:Float = 0) Local retpos:TVec3; pos.y = TerrainElevation(TTerrain(game.scene.terrain), pos.x, pos.z) ; if (pickheight > 0) Local pick:TPick; pick = LinePick(Vec3(pos.x, pos.y + pickheight, pos.z), pos) ; if (pick <> null) pos.y = pick.y; End If End If retpos = pos; Return retpos; End Function This next bit of code is simpler, it returns the height ABOVE the terrain rather than the actual terrain height but you can see how it works easily enough to adapt. It relies that you have access to the terrain entity which is normally done through some scene processor function if you're loading it from a file. CamHeightAboveTerrain = MyCamera.Position.y - TerrainElevation(TTerrain(game.scene.terrain), MyCamera.Position.x, MyCamera.Position.z) ;