[Failed Map Compiling]

You just need to compile the project once in Visual Studio so the executable is there. This has always been the case.

[Mipmap distance]

Are you talking about terrain? There is an internal command:

virtual void SetTextureStageDistance(float distance, float multiplier);

 

The default values are 16 and 2.

[Terrain textures]

Yeah, I know how to do that, but it doesn't seem to me that terrain layers take mat files but tex files instead. If I select a mat file for the terrain nothing shows up for me. Just wondering if that's normal?

That's correct.

[Leadwerks 3: Loading Entities in-game and LoD]

There was recently (yesterday) an update which fixed character physics on terrain.

 

Regarding your model issue, you are much more likely to get useful advice if you attach the file in your post.

[follow command]

The problem is it took too long to calculate the navmesh for a terrain if the whole thing was run in the background. In the future, a combination of static and dynamic navmesh geometry will be used.

[Project loading times?]

It sounds like there definitely may be a bug, but the example project does not produce this problem, so there's nothing I can do until someone gives me a project to try.

[lighting problem since update]

Basically, here's what's going on:

 

In the OpenGL 2 renderer, each entity can be lit by up to four lights. In the editor, each brush is a separate entity, and dynamic lighting works as you would expect. When the map is loaded in the engine, brush objects are collapsed into model geometry. This has the benefit of making rendering much faster. This is a very common idea in many FPS game engines, because BSP geometry is static, and there is no reason to keep invidividual objects when it's not being edited.

 

Your scene is being collapsed into a few big chunks, which has the benefit of fast rendering. However, the four light rule still holds, and your lighting does not appear the same. It is recommended that you use lightmapped materials for BSP geometry, as these will appear the same in the editor and engine when the objects are collapsed.

 

The OpenGL 4 renderer will use all dynamic lighting that always works the same in the editor and engine.

 

This behavior must have been the same prior to the update, as it has been designed like this since the beginning.

 

--EDIT--

 

Unless your materials actually do use lightmaps. Since you did not provide them, I can't tell if that is the case.

[New update issues.]

Thank you for the report.

 

1. Project loading time is 5 - 6 minutes, debug struggles to run. (used to be instant before terrain update) Ok so this is solved if i remove a particular model, YET in the leadwerks 3 before terrain, this model loads in a scene instantly?

Since you have not included the file in question there is nothing I can do to investigate this.

 

2.Cant create new projects, when the project is created and i press ok to load it, it creashes with Exception_Acess_Violation.

I believe this issue is fixed now in the Windows build. The Mac build will come later today. I believe this only occurred when a terrain was present in the map before switching projects.

 

3.Canot open darkness awaits from, same issue as above: Exception_Acess_Violation

It is likely this is the same problem as #2.

[Terrain manipulation at run-time]

Programmatic terrain manipulation is not presently supported, officially. That said, there are lots of things you can find if you browse the header files.

 

There may even be a World::BuiltNavTile(x,z) function that may even work.

[follow command]

Just make sure you calculate the navmesh in the editor.

[LE 3 Constants]

As long as it still needs the static lib or DLL you can post it here:

http://www.leadwerks.com/werkspace/files/category/5-code/

 

I never had any luck getting BMX to load a static lib made in Visual Studio without a DLL. The Mac version will work fine.

[Hinge joints never comes to rest]

Bug is confirmed with Julio:

http://newtondynamics.com/forum/viewtopic.php?f=12&t=7750&p=53315#p53315

 

The problem only occurs when hinge limits are used.

 

Apparently this is due to some changes he made when implementing joint actuators...if that's what I think it is, it's a welcome addition.

[Shadow mapping models Alpha?]

Ok, understandable. Am i right in thinking the openGL 4 wont work on ios? Just thought this would be nice for IOS outdoor games.

 

Andy

OpenGL 4 is PC-only.

 

At the moment, Leadwerks is still making the most sales in PC. However, mobile users have been increasing lately. It might be that it just takes more time to break into that market.

 

I'd really like to make the December deadline, so that means staying focused on the essentials. We can always add enhancements down the road.

[Shadow mapping models Alpha?]

Sure, I could do it, but it's always a matter of tradeoffs. I think my time is best spent on the OpenGL 4 renderer right now rather than making adjustments to the fallback renderer.

[Shadow mapping models Alpha?]

Ohhhhh, I see.

 

I probably won't do this soon because we'll have the OpenGL4 renderer soon enough.

[Shadow mapping models Alpha?]

Ah...Leadwerks 3 doesn't use shadow mapping yet!

[Shadow mapping models Alpha?]

Add this line to the material file:

shadowshader="abstract::mesh_shadow_sway.vert","abstract::mesh_shadow.frag"

[Hinge joints never comes to rest]

The hinge joints seem to produce excess energy when limits are enabled. The music is entirely coincidental, but appropriate:

http://www.youtube.com/watch?v=sJE1o-hXmkM&feature=player_embedded

[Shadow mapping models Alpha?]

The included tree models show how materials can use a shadow shader to perform alpha discard. This should always be used for trees, grass, etc.

[Hinge joints never comes to rest]

Those two issues are completely unrelated, since the character controller does not use the physics simulator.

 

I did quite a lot of additional modifications to the controller for tomorrow's update. Let me know if you have problems after that.

[Terrain outline in other viewports]

I decided not to render terrain in the 2D viewports because you just see a lot of overlapping hills, and it's very hard to tell what anything is. I might consider changing that, but when it was enabled, you just see a lot of curvy lines everywhere.

[Terrain set a layer to use as an active mask]

Isn't that sort of backwards? You have to paint the modifications into the paint layer, then you use the sculpt tool to roughly adjust it. Couldn't you just as easily sculpt the island, for example, and then use the height constraint to determine where the sandy textures are? I'm not understanding the major benefit.

[follow command]

New patch will be uploaded tomorrow to fix this and all other recent bugs.

[Terrain set a layer to use as an active mask]

I don't understand your description.

[No terrain tab on Mac]

Rick says he got it.