Josh

I added a vcproject to the Transparency and Refraction lesson. I'm going to include a project with each lesson showing the final result. Unfortunately, the Windows 64-bit Program Files convention interferes with this, because the project doesn't know if the header files are in C:\Program Files\Leadwerks Engine SDK or C:\Program Files (x86)\Leadwerks Engine SDK. I am going to make these projects with the header in C:\Leadwerks Engine SDK, and the default installation directory will be moved there as well.

The floor/ceiling sliders can be used to control the opacity.

There are still a few things I can do to improve performance with points lights especially. Multithreading won't actually make that much of a difference, because most of the bottlenecks occur on the GPU.

Within one month.

TerrainHeight will return the height at a specific grid point. Terrain elevation will return an interpolated height at a 3D position in global coordinates.

http://leadwerks.com/werkspace/index.php?/tracker/issue-25-road-position/

The issue is resolved. Sync.

Your first code you posted worked perfectly.

function object:Free() (no parameters)

Well, I think in my case docs and tutorials are the "seeds" and sales are what you reap.

If you add require("scripts/loop") at the top, you will import the loop script, which has a few functions declared the engine picks up: require("Scripts/hooks") function UpdateWorldHook() RunHooks("UpdateWorld") end function UpdatePhysicsHook() RunHooks("UpdatePhysics") end function FlipHook() RunHooks("Flip") end I just added the FlipHook() function, so I guess it doesn't make sense to call this file "loop" anymore. Maybe "enginehooks" would be a better file name? Then the user can use AddHook("UpdateWorld",myfunction) to add their own Lua hooks, and your main loop doesn't have to have any code hardly.

You could but the results would be unpredictable because SetMatrix() updates the entity position, rotation, scale, etc. Here is a list of members: http://leadwerks.com...ntities#Members The following are the documented members of the Entity class. Generally, members should be treated as read-only. For example, setting the entity position by changing the position vector values will fail to perform necessary updates the SetPosition() command would call, and the results may be unpredictable.

Me.

It sounds like perhaps some files got moved around and you are loading an older version of the script? Double click on the class node of the pointlight and see what the script is.

Yes, and SM4 is unique because that is the point where you can finally have full lighting. After that, you can just rely on the same techniques and increase the resolutions with hardware.

You can put variable in the class table. You should be able to see how it works now.

I thought it seemed sort of redundant when you have the member itself to access.

This is a good idea to keep in mind, especially with something like software development: "Don't judge each day by the harvest you reap but by the seeds that you plant." -Robert Louis Stevenson

That's true.

Thanks for making this. I added it to the sync folder.

Right.

Okay, there is a confirmed bug where the roads don't construct properly when meters per tile is other than the default value. The number 2 is probably hard-coded in the script somewhere, so I will find it.

How do I produce this result?

http://leadwerks.com/engine_tutorials.html

The world has a list of entities. You can also look for a specific class in the classnametable: local class=classnametable["light_directional"]