Flexman

If I might make a couple of suggestions based on things I would have liked to have had; Support for serializing and deserializing vegetation data so it can be loaded/streamed when working with tiles or tiled terrain. And the implementation of world modifiers; primitives such as spheres that add an offset to vegetation, simulating movement though tall grass, or localized wind movement (such as a large fan). Seems to me you can use this for clouds and general ground clutter. Clutter doesn't need to interact, just be there to present visual noise; e.g leaves, small rocks.

The artist can create a number of 3D props that use the same material, placing the textures from all the props on one texture. If they map the texture coords appropriately then it's a fairly trivial optimization. Since props using the same material get batched together it will save on internal material switching. Reducing draw calls in Unity is a quick and easy level optimization, especially for mobile devices. In for desktops I'm not sure it's such a great return on effort if you're only talking about a few instances. But in principle (and in practice) it works.

Curious; what AABB test(s) does CameraPick do first?

Use ModelViewer.exe and drill down through the model tree-control on the left until you find the bone you want (or not if they are missing). At least you can confirm what is in the model and identify any export issues you may (or may not) have.

I would say testing begins before you write any code. We've got a fairly good size community for CombatHelo but still very much under the radar. Getting some popular YouTubers on board by giving them access to builds can kick up a lot of interest. You have to time it right though. We're going through all this pain right now. Polishing working builds prior to sending out to selective gamers and Greenlight. Scares the **** out of me once it's out there, it's no longer in my control. Not everyone cares about art, but a lot do. You can publish non-structured games now, they seem to have been adopted as a kind of game in their own right.

I just read the pinned post about Intel/ATI graphics GPUs, we recently came across this in the wild when testing our game. I want to know if there's some method with Leadwerks engine to enumerate and specify a graphics device before initialization? Some of us have multiple displays that want to run in true full-screen without having to use a borderless/full screen window which is a performance sink.

Is it compatible with Re-Sharper?

I'm just throwin in my 0.02$ from an LE2.5 user. LE would go to your hook first (if defined), then the internal update which you can't see. We've done a lot of this recently.

I bought into the LE3 mobile SDKs to show support. I'm glad it wasn't such a huge layout. What I *wanted* was LE2.5 with OpenGL 4 and better tools. Maybe some of the streaming stuff that was talked about. Linux is the new toy-boy thanks to Steam, I don't know how long that will last. Ouya got a lot of press then reality arrived in the post. SteamOS is cooling off and we've not seen much in the way of a breakout yet. I remain hopeful and enthused by some of the content posted by new LE3 users. It's frustrating that to this day, I still spend most of my time working around LE 2.5 limitations to achieve things that should be quite simple. But the awesome thing is, every big problem I came up against I've been able to resolve with a lot of heart-ache and creative use of the semi-open nature of the engine. In the end, much more rewarding. (Source would have been more awesome.) I'll just finish by saying I have had a very real love-hate relationship with Leadwerks engine. Hell, they didn't even send me a t-shirt even though the company used a personal photo of our Christmas tree with the kids presents under it in a promotional post last year. It was funny as hell to see (especially our lovely brown curtains). I lost out but then I knew that ahead of time anyway. Josh needs to do this. Last time Josh changed tack, some of the old community deserted to other engines because they were not interested in mobile. Josh went ahead and did it anyway but you have to keep in mind that there's a certain silicon valley mentality that's OK to try things and fail. You learn and try the new thing. It's something people could learn from. Failure is an option. I still want a bloody t-shirt from the tight git for the Xmas tree thing though I look forward to seeing a renewed focus for the desktop which is what he's best at. Maybe upkeep of the mobile engine could be entrusted to the community under a strict usage license. Just a thought if it's not going to be doing anything in future. All the above is just my personal ramblings.

Has anyone played with the OpenAL doppler commands under Leadwerks 2.5x?

Funny that for DK2 they went to the old tried and tested technology that TrackIR uses for head-tracking. Another unit to stick on top of the monitor. The guys from TESTED dot com gave their impressions of the unit and the demos they'd seen. I think there's a space for small indie games and apps here. Looks like everyone else is kicking back and waiting to see what happens. There was even a Blitzmax demo for DK1 kicking around. Now they've got the translational movement drift issue sorted it might be worth looking at again. I can see it being as useful as TrackIR, something that you keep around for those few occasions when you use it as when you do it enhances an already good experience. But it you're using just for the experience of VR, it's going to get tired quickly.

You can use that. This is an example. e is of type TEntity en is a string scene = LoadScene("abstract::myscene.sbx"); childCount = CountChildren(scene); for(i=1;i<=childCount;i++) { e=GetChild(scene,i); en=GetEntityKey(e,"name"); ... ...

Another gotcha from LE2 days

I wish it was possible to do this with LE2.5, there are some elements that would benefit from hardware tessellation. Wires and roads for example.

Always a pleasure to read.

Yeah. I've played with the C# stuff for 2.5 and the new stuff. It's great but not complete.

Not had to do this myself but I'll jump in just because it's an LE2.5 question. There are at least two states when in water. Floating on the surface and swimming underwater (turn off gravity for this body when buoyancy is neutral). If I had to tackle it, I'd start with having a cylinder with buoyancy and when the character enters water to the point where our character should float, update the controller position with the forces from the buoyant "float" entity. If we want to swim under water, we don't do this. Instead we'll need to turn off the buoyancy of our float and ramp up the dampening really high to "swimulate" the weight of water. But still update the controller with out float body forces etc. Might work.

This is what I do everyday professionally, a combination of automated, manual and unit tests. Just adopted Coded UI for GUI testing. It always IS a pain but it's how you ensure quality and reduce the number of bugs that reach your customers and giving a ****ty impression of your product Even having those testing processes in place demonstrates you take quality seriously. You can do it for graphics, certainly you can have tests that check physics, parenting, hiding, movement and confirm these entities behaved as expected. Generally test cases are different from unit testing and involves manual testing to confirm that when you do action "a" you get result "b". (Think of all those small examples in the documentation, could be tweaked for a regression test suite to be run every major release). End users shouldn't be doing this for middleware, your own code maybe.

It sounds (no pun intended) similar to what happens in LE2.5 when you don't have a "Listener" attached to the camera. Listener objects are needed to spatialize sound.

If you increase the LinearDamping that should increase the friction. That's the easy way. The alternative is to start getting into cancelling out forces (get/set velocity etc) as others mentioned above.

I like that blend pattern usage. Has this been implemented in LE 3.1? I should modify the terrain shaders to do that for our project before we release. It looks much better. When in doubt, check your alpha channels.

Do you think LE2 could be made to work with it? I keep getting asked about it. As far as I'm aware you need to render the scene for each eye which I think might be expensive to do in a heavy outdoor scene with post effects.

I'm fascinated by Rastar's terrain mesh tessellation exploration. With large landscapes once you've licked the problem of the terrain mesh you have to deal with vegetation then any civilization layer for roads/buildings and finally collisions. It all adds up to (as Rastar says); a long and twisted journey. So I would seriously consider something small if you can get away with it. Having multiple-terrain objects in a scene and having everything in it parented to the terrain entity would be ideal.

And add little corona at the end to look like a spot scattering reflected laser light.

DudeAwesome's suggestion will work fine. In LE2 you had a PickFilter callback which was really handy for this kind of thing. We had a slightly different problem, scan large areas containing 1 to many widely spaced entities (for simulating radar sweeps). We would first compute an axis aligned bounding box for the scan volume, then generate a collection of potential entities using worldforeachentityinaabbdo then reject based on angle of entity to the source. The final step was performing line of sight tests on the remaining collection. Since radar sweeps occur every few seconds it's not a problem spreading the task over time. A different problem but the above might help someone else trying to do the same.