Pixel Perfect

No, you're quite right MG it's not. A* is still the primary route solver used with nav mesh systems. They are after all a collection of nodes.

I've heard of 'blowing your own trumpet' but that's a veritable fanfare

Needs addition of a PublishGameForMe(std::string publisherOfChoice) command too .... no point in doing half a job eh

I wasn't trying to be wise; just simply responding to Kevin's comment and pointing out that the consequences to Josh of guestimating the engine cost at this point are real, as Josh has already highlighted, whilst the consequences to Kevin are zero at this point.

Thanks for the feedback Brent, much appreciated!

That's the whole point I'm making ... the artwork was not produced in Leadwerks so why post it in the Leadwerks Showcase! Other artists who have posted work in here have had their posts moved and quite rightly so. It's nothing personal, this is addressed more at the forum moderators. It's just sets a bad president and will leave others who have had their entries moved feeling like double standards are in operation! No one is saying you can't post your work in the forums, that is encouraged, just that it needs to be in an appropriate place. I personally think a slot for third party tools and assets would be a good idea. A single repository for items like your company's Elixir and the many asset based company entries we get.

I'm sorry but I really do object to this being in the Leadwerks Showcase forum. It has not one line of Leadwerks engine code in it and has no more place here than any of the other items which have appeared and subsequently been moved by Admin. Why is an exception being made for this? It may be a very good product (only time will tell) but it is none the less a third party tool and is not showcasing anything coded with Leadwerks Engine. I am quite happy for people to advertise there products in the forum however I respectively request that this be moved to off-topic where it rightfully belongs.

That does look interesting Guy ... I'm taking a look as I've not decided what scripting language to implement yet in my Leadwerks based engine. Thanks for the recommendation.

Well it was the change to GPU from CPU that killed me being able to use my 7900. I had exactly the issues Jay is refering to (mine would go away for minutes) and was forced to upgrade my card as drivers never sorted it! The rest of the engine ran fine, it was just in the terrain editor when painting.

Have you managed to lose the vertex weightings along the way somehow? The mat file looks ok and if the bones are moving that's the only thing I can think!

Thanks for the reply. I've posted a few questions in your Off Topic thread Krankzinnig

Decisions are always easy when the consequences do not affect you

It's good to see someone trying the Leadwerks Networking again. I have no need for networking presently so I've never looked at this but I'll look forward to seeing if you manage to get it all working. Good luck!

Like Rick, I think I initially misunderstood what you were describing thinking you had written your own database system. From your later comments regarding it being a 'middleware layer' I'm now assuming it's a front end for an existing database engine like MySQL. You might want to clarify this. The UI does look great btw but I'm not sure it belongs in the Leadwerks Showcase forum as it is essentially not a Leadwerks product.

It's simply to ensure there is only ever one instance of this defined, any attempt to add a second #include "netwerks.h" will not attempt to redefine the same contents if they have already been defined. It should be left in. netwerks.cpp will reference the header as an include so the include file either needs to be included in your project or at least the path to the include file specified in your compiler options.

It's straight forward skeletal animation Dan but I'm completely perplexed as to how the animator has managed to get so much movement from the rig I'm looking at when I open it in fragmotion. It appears to be a pretty standard rig except for an additional bone behind the mouth region. To get the amount of movement and facial expression the animator has to have done something pretty amazing with the weightings. I think ArBuZ was accurate with his observations, this is clever stuff! Pic of wireframe and skeleton below:

It's the animated weapon meshes. I have them parented to the camera and for some reason up to and including 2.31 these never got picked. Now they clearly are being so I guess I need to filter these out using a pick filter routine. Phew ... glad that one's resolved!

It's returning the camera or rather a sub face of the camera. Even CameraPick is returning the camera. Now I'm totally confused. Why would CameraPick pick itself? Or ... have i got something parented to the camera that it's colliding with and subsequently resolving itself to the camera as a result of the heirarchy. But then, why would that not have been an issue before 2.32? The only thing listed in the vesion changes for 2.32 to do with picks is:

I have a model with an animated mouth and face to simulate simple speech and facial expression. It runs beautifully in LE2 with no hit on performance at all.

Thanks MG, yes indeed I'd forgotten your woes of that time as I see I partly contributed to that thread. I agree with your recommendation to move to the latest version, which I did last night. The issues on the whole seem fairly small as I ran through most of my engines functionality and it's just this one picking mechanism I'm using that is exhibiting problems along with a small issue with coronas. However, the pick problem is pretty fundamental! In the case of EntityPick I'm not using custom filters but simply running it with the collisionType set to 0 and then submitting the picked entity (essentially whatever it hits first) to a function to return the top most parent (or itself if there is no further hierarchy). I do use filters with some of my CameraPick calls and as far as I'm aware so far they are still working correctly. In the situation I'm using it I can substitute in a call to CameraPick easily and if that works then I'll simply run with that. If not then I'll have to examine my code some more and just check it's not me doing something daft

Looks like the function is returning entities which are not children of the target model, so quite what they are I'm not sure at the moment. I'll replace with CameraPick, which is working fine, tonight and see if that fixes it.

I've been using version 2.31 to develop my engine as I found it to be a very stable version and I had a lot of code to write. Now I'm looking to move to 2.42 to take advantage of some of the later features. Having initially tried 2.32 I seem to have an issue with my destructible objects which I've managed to track down to the EntityPick call. This is the same still in 2.42 and it appears to only pick the models if I'm right next to them, any distance away and it fails to return the model even though there is nothing in between and regardless of any range value setting in the parameters. Can anyone else confirm if this is an issue for them. Works perfectly in 2.31 but not in any of the later versions.

lol ... funny how that happens sometimes

I agree with that, having a threaded LoadModel function with a callback is the critical component. Anything else in terms of complexity could be built from that.

Well I'm sure you have a lot better idea than me Dan as my modelling skills are pretty much zero Hope it works out as that would indeed be a very flexible technique.