Flexman

A circular 'ring' mesh that uses the same vert shader as vegetation to keep it aligned to terrain. Offset it above the origin a bit. There used to be a terrain decal in downloads somewhere that might be good enough. Another approach is to use a spotlight with a material to project a texture image (might need to replace the spotlight.gmf model with something that is invisible). Good for RPG style spell effects.

I had a parenting scale issue with a mesh entity (missiles on launch rails) and something interesting happened. When I used LoadMesh(...) for the missile objects they would scale oddly. I used LoadModel(...) on the same missile model and no scaling issue after parenting. I wondered if you guys might have come across this yourselves? @VeTal Quick question, where is the pivot/origin of that sword model?

Yes. Configurable game input is a pain when it shouldn't be. Most implementations of input libraries fall short, SDL uses the Windows Media layer which is a poor-mans joystick interface that can't address all the axis and buttons you get on high-end devices today. Documentation says you should be able to read up to 8 axis but in practice you can only read axis on drivers that map them to the WML interface, which is often only sub-set. Might be good for simple joypads and low end devices but useless for exotic controllers such as Thrustmasters and Saitek Pro devices. Really need a good DirectInput interface/wrapper.

Don't laugh, I used to USE those punch cards for COBOL. In most languages the first program you write is "Hello World", in COBOL your first program output a list of financial transactions. Plus you had to get your indenting correct, if your program sections were one character out of alignment your program would be garbage...literally. Hence garbage in and garbage out.

You're wanting to access a LUA object from you main program code? Off the top of my head... And in BMax before you load your scene, make an object and assign a name as a reference you can access in your script... Local tempObject:Object; SetGlobalObject("car_chassis", tempObject ) ; ' LOAD A SCENE ' ' Cast tempObject to whatever you need ' Local carmodel:TModel = TModel(tempObject); In the LUA script set the object pointer to the name ... SetGlobalObject( "car_chassis", chassis ) There's some older threads on this, search on "SetScriptObject" and "SetGlobalObject"

Some tools to get data into a game would be handy. An XML read/writer and/or simple SQL engine. Raknet intergration too.

There is if you use a lot of them. Have them on a reasonably fast recycle time and it's quire reasonable. You get better performance using your own quads instead of a TPlane. This creates a simple two triangle square (like TPlane) and you can move and paint with your billboard material just like a TPlane and it worked out faster for me since I don't need any AABB updates from them. They are typically short duration meshes that are always visible if the parent missile is visible. Every time I create a 'particle' I'm making a quad like this... Self.Sprite = CreateMesh() ; Self.Surface = CreateSurface(self.Sprite) ; Local surf:TSurface = Self.Surface; AddVertex(surf, Vec3(-1, 0, -1)) ; AddVertex(surf, Vec3(1, 0, 1)) ; AddVertex(surf, Vec3(1, 0, -1)) ; AddVertex(surf, Vec3(-1, 0, 1)) ; AddTriangle(surf, 0, 1, 2) ; AddTriangle(surf, 3, 1, 0) ; SetVertexNormal(surf, 0, Vec3(0, 0, -1)) ; SetVertexNormal(surf, 1, Vec3(0, 0, -1)) ; SetVertexNormal(surf, 2, Vec3(0, 0, -1)) ; SetVertexNormal(surf, 3, Vec3(0, 0, -1)) ; SetVertexTexCoords(surf, 0, Vec2(0, 1)) ; SetVertexTexCoords(surf, 1, Vec2(1, 0)) ; SetVertexTexCoords(surf, 2, Vec2(1, 1)) ; SetVertexTexCoords(surf, 3, Vec2(1, 1)) ; ScaleMesh(Self.Sprite, vec3(Self.Size)) ; Self.Sprite.SetPosition(Self.Position) ; I'm using about 100 of these particles. A small loop adds around 10-20 of of different sizes to the tail-pipe of a rocket which moves so fast, blink and you'd miss it. If all the quads shared the same surface it should be as fast as you can probably make it. Updating is done ia pretty small loop in the manager. Particles is a linked list (TList). Method Update() For Local p:TParticle = eachin self.Particles if p.IsDead p.Free() ; Self.Particles.Remove(p) ; Else ' UPDATE METHOD FOR EACH PARTICLE ' p.Update() ; End If Next End Method And the update in the TParticle object checks for death and alpha fade.... Method Update() Local tim:Int = AppTime() If tim >= self.Timer Then IsDead = True Else if (tim >= (self.Timer - Self.LifeTime)) Self.Sprite.SetColorf(self.Color.x, self.Color.y, self.Color.z, ((self.Timer - tim) / Self.LifeTime) * Self.Color.w) ; End if EndIf End Method

Are those headlamps separate models added to the car? If so (and they are easy to remove) try without. See if that does anything. Just a shot in the dark.

I saw this book going cheap (damaged stock) and picked it up. It's one of the better basic-principle game programming books I've come across with nice practical diagrams of using vectors and examples of why you might want a dot or cross product of something in your game. One you'll want to expand upon though. Lot of 2D sprite discussion. I'd also recommend, Game Coding Complete.

Generally I shy away from these discussions. All that matters is getting a job done as painlessly as possible, I don't put languages/engines above the other unless it inhibits the end goal in some way. If I were a mechanic servicing a car one spanner is much like another. So long as it fits. Unity has a footprint that's recognised by studios, some of the interviews I had with Codemasters and the like were Unity centric. They want Unity programmers for the social gaming gold-rush. You can pull in a lot of really bad community or asset store scripts that come in different languages that don't *quite* do what you want and throw out some polished (disposable) content in a short amount of time. My LE experience has been marginally better than with Unity. I really don't like scripting, it hides things from me. When it comes to script implementations, how do I know when something is getting processed by the engine? What are the performance costs of doing animation at the script level as opposed to iterating in compiled code? Is the implementation complete? How can I verify? I have problems with LUA scripts in LE (model scripts) and will avoid if possible. I tried it early on and came to the realisation for doing mundane things like blinking lights it's fine. Script errors can go hidden and simply stop further processing for a model with no indication as to what is wrong. Debugging anything complex is simply not worth the time. Unity scores big time with the ability to pause to step through scripts and watch values. If I could do that with LUA in LE then it might have saved some time, I'd still shy away from complex scripts because of the level of doubt that comes with it (I think it unlikely that the LUA interpreter in LE is threaded, I don't know this, it's not documented anywhere). Not everyone is performance centric though. Mono I know little about. As a language it seems much like any other, differences seem to be strength of typing (Oh goodness I have issues with LUA for that but that makes it ideal for artists) and the objects used. All I care about is performance and ease of use. So after 5 paragraphs that I suspect nobody will read, I have no opinion on Mono except I don't like scripting too much unless there's documentation about implementation and performance. What a waste of time this reply was

Aily gives you the math which is better. If you're feeling lazy.... dist:float = Vec3(x1,y1,z1).DistanceTo(x2,y2,z2);

It occurs to me, throw imposters into the mix and it's a good basis 3D cloud s. For imposters you just update them if the camera has changed more than a trigger amount.

One thing about the billboard shader vertex transformation, it doesn't work to well if you change the camera zoom level (fov). vertexcameraposition = (gl_ModelViewProjectionMatrix * mat[3]) + vec4(gl_Vertex.x,gl_Vertex.z*(buffersize.x/buffersize.y),0.0,0.0); A narrow fov makes the billboards 'shrink', need to fix that. But yes, very helpful post, cheers Mack.

Particle engines are commonly used for fire and smoke effects adding a lot of eye-candy for little effort. Every frame an emitter creates a number of billboard sprites along a vector. Normally this is not an issue when movement along this vector between frames is quite small. But what if you're talking about something that moves really fast between frames? Such as a rocket launcher or space-ship? Fellow Brit and indy developer Cliff Harris of Gratuitous Space Battles fame ran into the same problem. Here's a screenshot from his blog of a rocket. The rocket moves too far between frames to space out the particles in a pleasing manner. By adding a line of particles between each frame update a more pleasing effect is achieved. In Combat-Helo the hero-ship is typically loaded with several 70mm rockets that accelerate to 700 meters per second in approx 1.5 seconds. Even maintaining a short smoke trail of 10 meters can't be maintained as the rocket distance between two frames might be 50 meters or more. A linked list of billboards (TMesh CreatePlane()) is being trialled. UsingMacklebees billboard shader tweak and changing... ... gl_Vertex.x,gl_Vertex.y to ... gl_Vertex.x,gl_Vertex.z ...to work for Planes a 2D billboard function was implemented which handled colour and timing properties with a deviation (waver) offsets. This creates a ribbon of 50-150 quads (TPlanes) aligned to the camera using the billboard shader. Scale of each quad is roughly double the space between them to ensure some overlap and consistency. The smoke texture has baked lighting with a normal map however a normal map is redundant since the quad is camera aligned and rendered in the transparency layer. The spacing produces a good fill between two positions each frame. In the example image below the length of the trail is 75 meters, each particle doesn't require much updating since this was written for a specific purpose. As the shader takes care of orientation only timer tests, waver and alpha-colour needs updating although some extra instruction for management could be implemented (see footnote). Don't attempt to use ScaleMesh() as that slows the whole pipeline down. If you need to change the size of a particle you'll either have to do it in the shader or delete the particle and replace it with a larger one. Same again showing the AABB of each TMesh/Plane. That's about as fast I can can come up with using LE commands. The next stage is to replace the TPlane billboards with a single entity built using a TMesh and adding triangles as needed. Other optimisations might include changing the number of particles depending on the 2D length between the head and tail. We need more 'filler' if seen from the side than head on. Worst case would be a full salvo from 4 pods (each pod carries 9 rockets), in this event the particle manager could limit them. With the Leadwerks emitter function, once created you can't change the number of particles so having this level of control is handy for all manner of effects that need adjustment over time. This is of course slower than the LE particle system.

It's eliminated the bulk of the pausing on our games firing range, when you are spraying lots of lead around it was pretty annoying. And the AABB fix solved AOE damage testing too. Only thing I still have problems with are coronas, I'll look at those later. Can the new DrawEach() be used to paint different skins on player vehicles you think?

Yes, do tell us more about that water demo.

I've been using TModel.Copy() Your pole (or oildrum) will be stored as a *single* object which is drawn 10 times during the scene render. If you manipulate a vertex on your pole then all of your poles would change, likewise if you paint one of your poles with a different material then all of your poles will change to the new material. As Lum suggests LoadModel() works too, if already loaded it returns a pointer to the object.

We use a separate 'cockpit' world to render personal inventory items (guns, map, compass) and helicopter / vehicle cockpits. It has over advantages too, it prevents intrusion of emitters, water and fog effects into these spaces. And you can keep the object co-ordinates of this space at the origin so there are no precision or zbuffer problems and camera ranges are pretty shallow too. The downside is you have to handle continuity of lights between worlds. I duplicate the directional light in such a world using something like this (edited for simplicity)... MyGame.CockpitWorldDLight.SetRotation(EntityRotation(MyGame.PlayerCcontroller, 1).Minus(MyGame.SunLightPivot.Rotation).Inverse()); This moves the cockpit world directional light around the vehicle in such a way it matches an objects rotation in the main 3D world (where the 'sun' is a directional like parented to pivot "SunLightPivot"). Duplicate ambient light where appropriate. Muzzle flashes are easily duplicated in both worlds if needed on a weapon. This might sound like total gobbledygook and overly complicated, often simple is best but this worked best for us due to world scaling/environment and precision issues. In a nutshell, after rendering the main 3D world, the depth buffer is cleared, cockpit world rendered then drawn over the top.

Vegetation data is a flat file format, each 64 bytes would be the 4x4 matrix from GetEntityMatrix(), place one veg item, save, and you should have a 64 byte file containing the matrix for that vegetation entity. You'll have to find some way of sorting the data spatially, I'm not sure the saved veg.dat files are grouped in any particular way.

I used a combination of ModelDetail(n) and TerrainDetail(n) when rendering second cameras for TV monitors. You can also use a filter (RenderWorld(...)) and reduce the camera range of your mirror cam to speed things up. I've done it for a weapons camera, if you don't go overboard with real-time shadows (I recommend turning them off for a mirror camera pass) it should work really well. Additional performance can be had by frame skipping the mirror cam update. Just update the texture every other frame will greatly improve overall performance.

I'm confused by problems with tree normals. I have a lot of flat looking trees, when a directional light is low down this exaggerates the flat nature of the LOD1 trees (see attached image). Given the low poly nature (pun partially intended), what's the best practice for arranging vegetation normals with Leadwerks?

You'd think it would be available on Steam

Yes, that would be perfect.

I like the waterfall effect, sometimes whatever works has to do. And I fully concur with Ricks MAGIAM comments, it really is about project management and what you can get by with. When up against tight deadlines there may be many ways to skin the cat, BUT you only get to choose one. It's hard to do but good a discipline to practice, something I keep telling myself.

Yes, global values so they can be accessed by all shaders like the existing ones listed on the wiki here http://www.leadwerks.com/wiki/index.php?title=Shaders That would make it easier to apply some effect to many entities that don't share the same shader, or globally change a co-ordinate system.