Rastar

Yes, it was set to 0 and setting it to 1 activated the expected behavior. Thanks!

There never was C# official support for LE2, either, only C# wrappers provided by the community. And as much as I can understand your wish (since Java and C# development has been my job for more than ten years by now), I think it would be a step in the wrong direction. One of Leadwerks 3s main selling points is "native code" to avoid the overhead of a virtual machine especially in the context of mobile games. And if you already know C# (which is a very feature-rich language) you shouldn't have too much difficulty picking up Lua.

Regarding object creation parameters: Actually, another thing that I find cumbersome is the fact that I can't specify a CSG's size in input boxes. Yes, I can modify the scale, but to create a box of, say 10x10x1, I would have to draw that in (two different) viewports. My preferred way would be: 1) Right click on parent -> Create->Primitive->Box => creates a default 1x1x1 box. Focus is on the first of the (new) size input fields. 2) Enter target size 10 Tab 10 Tab 1 Enter By the way, currently I always have to hit the Tab key twice to move to the next field, once would be nicer.

It might already have been posted in one of the many Editor Workflow posts, but just to be sure ;-) I still find the using "Objects" tab for creating entities too cumbersome. I really would prefer an extension to the context menu in the scene tab with entries for "Create->Primitives->Box", "Create->Compound->Arch" etc. The objects would be created as a child of the currently selected object. Copy & Paste in this menu would be great, too.

I'm facing similar issues, and I think it might have something to do with the hierarchical structure of models. I tried the following: 1) Create a CSG box -> Navmesh is generated (for the generated box, "Navigation obstacle" is checked right after creation) 2) Create a pivot and move the CSG box as a child under the pivot -> navmesh still there 3) Uncheck the "Navigation obstacle" -> navmesh gone 4) Check "Navigation obstacle" (on box or pivot, doesn't matter) -> navmesh still not visible. 5) Move the CSG box under root again, uncheck and check "Navigation obstacle" -> navmesh back again Since models are imported with a parent-child relation (SKIN_MESH, then the model) and with the obstacle box unchecked, they're facing those problems "by default".

Sorry for bumping this thread, but... Is there anything special I have to do to activate pathfinding? I have imported models, generated a phy shape for them (or just used a boxes for some) and attached it to them. But whenever I activate "View->Show Navigation" there is no navigation mesh visible. I tried checking the "Navigation obstacle" flag on the objects, but to no avail. Oh, and by the way: There is a new numeric "Character" input box below "Collision type" that I can't find in the docs - what is that?

When trying to generate a physics shape of type "convex decomposition" the engine throws an error "Failed to launch C:\Leadwerks\Editor\Tools\Hull.exe". Which makes sense, because it doesn't exist

When removing a shape file from a scene model, its representation in the "View physics" mode isn't removed. Turning "View physics" off and on doesn't help, only closing and reopening Leadwerks.

C++, Lua is working fine.

I would suggest to supply configuration parameters for the angles, similar to a directional light, with the current angle being the default. That way the user could choose which settings suit the situation best, and it would be easy to enter the same values as that of a directional light, if present.

I was a little confused by the following picture, showing the default start map and a model with dynamic shadows turned on: Judging from the box's shadow, the directed light is coming from the front, whereas the dynamic shadow looks as if its coming from above and slightly behind the model. In addition, the model's shadow looks to me rotated by 180 degrees. Edit: I take back the 180 degrees thing, that seems to be OK, but the "source" of the model's shadow really is coming from high above and slightly behind the model.

Well, meshes and maybe materials should be instanced, but their assignments don't have to be unique. If I change the base model and assign materials to it (e.g. in the LE material editor) those changes should apply to all of its children, but if I change a child (in the viewport) that shouldn't propagate to its parent (and thereby all children). I do forfeit the advantages of instancing, if I have to copy the model (with exactly the same geometry) just because I want to assign a different material to it.

It seems that materials applied to one copy? instance? of a model in the viewport are always applied to all copies? instances? of it in the map, which is awkward. I am using some wall + floor meshes (Steve's Sci-Fi interior pack, btw) and I would like to apply different materials to those pieces, depending on where they are used. Yes, I could copy the model, but that shouldn't be neccessary and would be a waste of resources.

If I create a new project, build and run it in XCode, it immediately crashes with the following message: SimpleTest.debug`Leadwerks::Entity::Move(Leadwerks::Vec3 const&, bool) at Entity.cpp:2150: 0x9e060: pushl %ebp 0x9e061: movl %esp, %ebp 0x9e063: pushl %esi 0x9e064: subl $36, %esp 0x9e067: movb 16(%ebp), %al 0x9e06a: movl 12(%ebp), %ecx 0x9e06d: movl 8(%ebp), %edx 0x9e070: movl %edx, -8(%ebp) 0x9e073: movl %ecx, -12(%ebp) 0x9e076: andb $1, %al 0x9e078: movb %al, -13(%ebp) 0x9e07b: movl -8(%ebp), %ecx 0x9e07e: movl (%ecx), %edx 0x9e080: movl 516(%edx), %edx 0x9e086: movl -12(%ebp), %esi 0x9e089: movss 28(%esi), %xmm0 0x9e08e: movl -12(%ebp), %esi 0x9e091: movss 32(%esi), %xmm1 0x9e096: movl -12(%ebp), %esi 0x9e099: movss 36(%esi), %xmm2 <=== Thread 1: EXC_BAD_ACCESS (code=2, address=0x1c) 0x9e09e: movb -13(%ebp), %al 0x9e0a1: andb $1, %al 0x9e0a3: movl %ecx, (%esp) 0x9e0a6: movss %xmm0, 4(%esp) 0x9e0ac: movss %xmm1, 8(%esp) 0x9e0b2: movss %xmm2, 12(%esp) 0x9e0b8: movzbl %al, %ecx 0x9e0bb: movl %ecx, 16(%esp) 0x9e0bf: calll *%edx 0x9e0c1: addl $36, %esp 0x9e0c4: popl %esi 0x9e0c5: popl %ebp 0x9e0c6: ret I am using the latest LE3 version.

After importing models via copying them to the project folder, they can't be used right away. They appear black in the asset explorer, you can work with them (e.g. copy them to viewport). You can also assign materials to them, but they won't work. You first have to open the imported in the LE model editor and save them, after which they appear greyish in the asset explorer and are working properly.

Under OS X, if you copy models and textures into the project folder, LE doesn't start the conversion. Rather, you have to close and reopen LE to start the process. Under Windows this seems to be working.

+1 for pathfinding: How to use the generated navigation meshes, and how to integrate this system with additional AI (e.g. waypoints) +1 for loading/saving game levels

From your description, I am not completely sure what you already have and what you still need. Anyway, to my understanding the current status/workflow for terrain in Leadwerks 3 is as follows: There currently is no heightmap-based terrain feature in Leadwerks 3, it is on the roadmap for version 3.0, though. Right now you would have to convert your terrain to a mesh and use that. Terrain generation tools like World Machine can export the heightfield as a mesh. afecelis has created a nice tutorial (http://www.leadwerks.com/werkspace/topic/6555-tutorial-blender-for-leadwerkers-and-other-3d-buffs/page__st__20#entry55569 , #09) for working with heightmaps in Blender. You can save several tiles of your terrain grid in your model folder and load them on demand. Expect to have some issues (cracks etc) along the borders, though, especially if you've converted heightmap tiles to meshes. It's not easy to make seamless tiling. What kind of choppiness are you experiencing? Is your heightmap resolution low? You could then maybe use normalmaps to give them a smoother appearance. If your noise generators produce choppy terrains you'll have to play with their parameters, or again you might think about using a terrain generator like World Machine, Grome or L3DT, they have for example realistic erosion functions that can also smooth the heightfield.

Sorry, my post was confusing: What I meant was "until the end of April 30th" or "just before May 1st", Californian time (do you guys already have daylight savings time, 'cause we do?)

And the upgrade discount is only valid until today (May 1st, that is)

Brushes can be copied via the Edit menu or the Copy toolbar icon, but not using the keyboard shortcut.

I just know that Ogre3D uses OIS, but I haven't used it a lot, so can't comment if it's good or better than anything else: http://sourceforge.net/projects/wgois/

Rick, congrats too! Just got this, very nice and inspiring!

+1 for terrain

Now with the GDC being over, is there a rough schedule for the next releases, especially the feature-complete 3.0 including terrain? And is the approximate road map that was presented here a few weeks ago still valid?