YouGroove

+1 for visible bones and names, so much missing.

Ahahah great. Used "generate normal map" once to test but never really seen this other one

Could it be possible to have a half sphere as a basic BSP primitive ? It is usefull for lot of stuff.

Could it be possible to have some default better UV mapping for BSP spheres. Actually it is too broken :

Nope. I talk about doing a right click anc hossing a new menu like "create material from texture" Would create the material with name of texture directly without to input the material name. That's just a suggestion and improvment on workflow, there are basic stuff lacking and lot more needed indeed.

Something that would speed up a lot material creation : Right click on diffuse texture and would appear a new menu item like : "new material with texture name" - It would create a new material with the selected texture name. - It would assign automatically the selected texture as the diffuse texture in the material slot So no more need to rename material and diffuse basic texture would be assigned by default.

Something that would speed up a lot material creation : Right click on diffuse texture and would appear a new menu item like : "new material with texture name" - It would create a new material with the selected texture name. - It would assign automatically the selected texture as the diffuse texture in the material slot So no more need to rename material and diffuse basic texture would be assigned by default.

drag and drop not working under Win7 for simple Tga files. Works without problem with some other 3D engines. Would speed up workflow a lot instead of loosing time with menu and selecting folders.

I abandonned, something went wrong with the map file unfortunately, LE3 crashing, even after re importing the project after LE3 re install. re install LE3 caus LE3 editor always loads last project and map even if they crash. The problem is the map contains all of your hours and days of work , if it crashes at each startup, you loose all your work, so i just loosed my beat them up project. I just hope it will not happen another time

I agree. But using pathfinding without any physics can suit lot of games styles. Just need to port this code to some Lua function : NavPath* path = new NavPath(); path->navmesh = navMesh; path = path->navmesh->FindPath(pivot->GetPosition(true), Vec3(10, 0, 10)); And this should be an option for people to be able to choose to use physics or not in Navmesh functions. And the result without physics is unbeatable like tested by Evayr : With my PC the FPS would drop to 1 FPS after 64 units spawned using physics and GoToPoint().. With the new way of pathfinding I get 1 FPS after spawning 1135 units who don't use physics anymore.

barbarian became invisble in the editor after changing shaders in model editor. (changed normal map shaders to simple diffuse ones) Restarting editor all is ok.

Nope, yo ucan put it in some C++ section. I will translate it to Lua as i need turrets rotating to player, if we have Math::ATan2(v.y,v.x) in Lua , it's possible.

Could it be possible to have that feature in Lua in the future ? Such increase performance if you just use the path infos without physics should be available for Lua users. Well any game not concentrated on physics would benefit such "LightWeight" navigation system, as Entities that would follow navmesh would not have to care about physics and environment in lot of cases of games like pure RPG, MMo style, RTS, tactics turn based etc ...

You could add usefull code like : http://www.leadwerks.com/werkspace/topic/7665-turning-objects-towards-other-objects/ Vec2 v = entity0->GetPosition(true).xz() - entity1->GetPosition(true).xz(); float angle = Math::ATan2(v.y,v.x); entity0->SetRotation(0,angle,0); (There is more stuff code in programming section that could be in wiki snippets) Another point, this WIKI could be in LE3 site under "Documentation".

Well if you have already used some scripting language with some 3D engine Lua in LE3 will suit you. The visual programming in LE3 will need you to program in Lua all the visual components of your game yourself.

That's confusing. 3.0 final build : this means a last build before beeing discontinued so, and after tha final build of 3.0 we'll have to upgrade to have new bug fixes..

Does it works with real physic shape collision of the model or some approximative box model collsion ?

A simple physic function available on other 3D engines, and super usefull very missing in Leadwerks 3. Actually in LE3 you make some fake collision detection using distance, can be good for some situations and game styles, but for lot of stuff real trigger when entering collision and having the name of object colliding (or list), would bring LE3 to a new level in terms of gameplay programming. Suggestion for future 3.1 perhaps.

It is not similar to my bug ? http://www.leadwerks.com/werkspace/topic/7873-simple-collision-physics-not-working-on-model/ Could you post a minimal scene example to download an test ?

ok , so when 3.1 will be out, you'll have to buy 3.1 to have new bug corrections like physics bugs, lua bugs or editor bugs.

Just curious : how will work LE 3.0 updates for people not updating (or updating later ). Will serious physics and other bugs fix beeing reported into 3.0 updater ? Will some general editor improvments beeing reported into 3.0 ? Or must people be forced to update ?

This is indoor only, If it was some terrain exterior part, this should really demonstrate more LE3 features, don't know if shadows and new lightening work on terrain ? The demo is still lightweight, too similar to old LE2.5 demos. I think the purpose is show lightening and shadows ? not FPS framework ? It will need HUD life and ammo, more ennemies for the demo perhaps ? caus it's a bit empty. In terms of framework , it is lacking FPS framework for weapons you can find in some FPS Creator tool : automatic rifle, bazooka , grenade, health pack, ammo pack management. Anyway well done. More advanced FPS demo and some adverts in FPS creator related sites could attract lot of people to LE3 (specially with super easy BSP system)

You should be able to use any size model on a game you create, seeing the picture it is more some Navmesh scaling issue as Navmesh polygons are bigger than your house. Why not proposing some scaling parameter in Navmesh tool ?

Will 3.1 bring during the new year a real library of full screen effects that you could apply by using checkboxes and sliders like LE 2.5. And also enable/disable full screen effects by code ? MSAA will be usefull , but would be great to have in the future lot more usefull ones to improve the 3D scene : -Bloom -HDR -DOF -Ambient occlusion -Motion blurr -Color correction -Color effects ( like heat scanners , grey colorisation image etc ... )

@Rick : Why not creating a low poly version that navmesh would be able to exploit and create walkable areas ? Some sketchup low poly than tweak with high poly version Or make a retopology of the high poly directly : A solution would simply be able to modify/add polygons in some Navmesh mode : Like add polygons where you want without any restriction ; this way you would make stairs walkable just by adding a big rectangle area etc ... Or tell Navmesh tool to use some low poly collision model for generating navmesh.