Pixel Perfect

Leadwerks is licenced per user, so whilst there is not generally a problem with installing it on multiple machines so long as it is only the licencee who is using them I believe what you are describing would require two licences. Josh would have the definitive opinion on this though.

Whilst I agree they sell garbage next to good products I think you'll find the PC gaming fraternity has always been the most discerning of all when it comes to gaming hardware and most take pride in it. Consoles were invented for people who were not interested or capable of doing so

Congrats but which model?

I guess that would be possible but if you want the original model to have physics too its simpler to just replace the original model with the new broken parts. I load and hide these beforehand then locate them to the models position at the time the break is required. The original model is assigned a breaking force and its only when this force is exceeded that the object breaks. So you can for instance push the crates around and they won't break but shoot them or drop them from a sufficient height and they will. Each of the parts have their own physics bodies so are still totally interactive after the object is broken.

Yes it's possible. I create models with preformed broken parts and then substitute those for the initial model at the time I want them to break. I add a small explosive type force to push them apart. This is all controlled by a series of object oriented classes and a manager and all the elements are configurable and defined in an ini file and loaded along with the main model at the start of the game level. I can load two to any number of broken parts and have other parameters to control whether they should catch fire or propagate explosions and allow an explosive radius to be configured. You just need to think about it a bit then implement some suitable code. If you go to 7:15, in the old video below, I demo some simple examples there: http://www.youtube.com/watch?v=L8sn5kA7eKs

You might be able to use GetBodyVelocity, I'm not sure if that works with a controller which is a kind of modified body, but failing that record the previous and current position and time interval between them every call of your update routine and and you can calculate the speed. Ricks ray cast might be a better solution as this avoids the actual slowdown and makes the agent look 'more intelligent'.

I believe it would, the problem here is definitely your graphics card. Leadwerks is shader intensive and requires plenty of parallel cores for processing, that's what will get your fps up, Your 8400 series has lower clock rates and reduced core counts, they are designed for budget systems. nVidia cards to consider as a minimum in decreasing age of manufacture would be: 9800 260 or higher 460 or higher 560 or higher Progress from a 9800 upwards depending on your spending capability. Bare in mind you might need to upgrade your power supply too though!

Combining decals and vegetation layers, which of course are not just limited to vegetation but will work with any model, does increase the flexibility. Decals unfortunately are very expensive on the frame rate so you need to use these sparingly. The base layer can be used to give some subtle variation to texture layers too.

Looks like it's objecting to you creating it on the root of C ... they don't like you installing stuff there. Just try it initially in My Documents to see if that cures it, you should have full permissions there.

@Maccklebee ... hard to say from the example in the video but yes; the example you give would be a typical use of a deflector. I'm assuming at this point that combinations of multiple attractors/deflectors would allow this type of behaviour.

Another cool video blog Aggror. Looks like things are progressing nicely, hope people respond to the communications issue as this is so important in any project. Good luck guys!

Brilliant, attractors and deflectors was one of the things I asked for when you posted for suggestions, really pleased to see this in there. Nice work Chris and cool videoblog.

LESDK.exe works fine for me too on Windows 7 64

I agree 250+ is extreme and no one is seriously suggesting we need that many but 5 is too little even when they can be blended with a base texture. Faded mip maps do reduce the tiling issue (although good texture design will limit this considerably) but they also produce this uniform blandness with distance that looks anything but natural even when blended with a base layer. I'd probably go with Michaels experience and suggestion of 9 -15 layers being about optimal. I'd be a lot happier with 15 especially if supported by a good decal system but accept that's never going to happen in LE2. @shadmar Many thanks for posting the shader, that sounds like an interesting technique and I'll certainly experiment with it. Is this more effective with simpler textures (like sand for example) as opposed to ones with higher detail?

I'm really not sure how many it would take to get much more effective looking terrain as my experience has been limited pretty much to the existing 5 terrain texture layers. All I know is that I struggle to get sufficient variance using this number and any increase or alternate mechanism that allows for more would be a huge advantage. I'm aware however of some of the physical limitations imposed by graphics card hardware which contribute to these issues so accept its not simply a limit imposed by the engine designer. I did come across an MMO engine a while back that appeared to offer 256 terrain texture layers, not sure how they were managing that or what possible compromises there might have been. This link has some interesting information and looks at various different techniques: TerrainAdvancedTextures

It's difficult to get good terrain texture cover for vast outdoor scenes in LE2 due to the limit of 5 terrain textures. Being able to apply a base texture has helped considerably but it is challenging to come up with texture cover that both looks good at ground level but also convincing over distant views. Sometimes a single stretched texture like this can be more convincing over a distance but does look awful if the player has to walk on it.

It just keeps on getting better

EKI One currently requires your engine to be written in C++ as it uses a C++ interface. In Leadwerks this of course does not preclude you from using LUA to script objects, as you know, but EKI One will not work with a Leadwerks engine purely written in LUA! However, the AI in EKI One must be written in LUA and is executed within the EKI One engine which runs in real time along side your C++ engine. The EKI One AI engine effectively runs an AI simulation of your game for you in real time and passes whatever information you need it to to your game for you to use. I hope this helps clarify the situation. I will finish the documentation to go with the EKI One Leadwerks Integration example this weekend. It's the only thing currently outstanding. The whole package will go to the Masa Group for final approval/comment prior to me releasing it immediately after in the Leadwerks Asset store. This is why experienced programmers will tell people to use C++, simply because it offers so many more possibilities to interface into other third party tools, not out of any purism as we are often accused of

Sounds great and I like the small scene in your current build. Good luck with the team expansion guys.

I will, but that's no where near as much fun ... besides, where is the report button

Spammers! This is where that LECP baseball bat would come in handy

Well, I assume that it's designed to take a pointer to a terrain entity. In Leadwerks all named entity types are fundementally just char pointers so it won't distinguish between a TTerrain pointer and a TModel pointer hence the fact it compiles; but the two are normally pointing to completely different objects. As I previously indicated, outside ot the editor non of the vegetation functionality is exposed. You might check Klepto2's community version of the engine.DLL as I believe that has exposed many more functions but I don't know to what extent the vegetation functionality is exposed ... if at all. Sure Josh could give a categorical answer to this but in the mean time I would assume you will need to implement your own system in totality if not using Leadwerks terrain.

I'm not sure I understand what you think you are doing in that code. You have loaded a model and created a function thats designed to convert a model into a terrain? If this is LEO I guess you just created an instance of a Terrain Class based on a pointer to a loaded model? Maybe you'd like to elaborate?

I'm saying that all of the vegetation functionality is tied into the terrain system. After all it deploys vegetation over the terrain, either all of it, at the press of a button, or it allows you to paint vegetation layers on the terrain. Either way a Leadwerks terrain is required. You cannot deploy vegetation onto mesh models! Nothing to stop you designing your own vegetation system of course and yes you might be able to use some aspects of the existing code/shaders but none of this functionality is exposed other than through the terrain interface in the editor.

For all things Leadwerks the best starting point is the Leadwerks User Guide however the vegetation system in Leadwerks is based upon the terrain system. So no terrain - no vegetation system!