klepto2

Hi, i have used SWIG with Leadwerks succesfully in the past and also use it currently from time to time. You can create your own dll by using the Leadwerks.lib under windows or the Leadwerks.a under Linux. Just create a new Leadwerksproject, remove all sources and add the generated header from swig into the project. Then change the project properties to compile to a dll (or the same for linux). For getting a complete Wrapper you need to fix alot of definitions and make use of a lot of SWIG tricks. I would recommend to start only with the classes and things made public to lua and extend on that.

Well, sure the Skybox might not be needed for Lights, but is needed for Probes. In general the Camera provides functions to render the scene and this is needed for probes and shadowmaps. You get all the info with the API-reference.xml as well. the filename usually looks like this: API-Reference_Object_Entity_Camera_Light_DirectionalLight Strip the beginning and split by _, then you get the whole hierarchy of the class. In some cases there is a something like Object_Math_AABB where Math is not a real class, but if you register all class names before parsing the actual class you can identify these and ignore those 'pseudo' classes.

I think that is correct. The Light and Probe classes are inherited from Camera class which makes perfect sence as both need the same behaviour as a camera. I am trying to generate a intellisense implementation by myself and i have come across this: https://www.leadwerks.com/documentation/API-Reference.xml This seems to contain all classes available in Leadwerks and is easier to parse than the toc.xml,

this is not the Documentation of Scintilla, it is the documentation of Scite,a Texteditor which uses Scintilla and is developed by the same guys developing scintilla. The implemntation is unfortuntly no one liner as you assumed. Why it should be no big Task, such Features could bring a big Performance Impact if not done right.

Hi, it looks like you're mixing a matrial shader and a postprocess shader. should this shader work per instance or as a post process shader? If it should be a postprocess shader: These variables: //Inputs in vec2 ex_texcoords0; in vec4 ex_color; in float ex_selectionstate; in vec3 ex_VertexCameraPosition; in vec3 ex_normal; in vec3 ex_tangent; in vec3 ex_binormal; in float clipdistance0; [/Code] are not available and Need to be calculated from the depth/normal buffer provided via a lua part of the post process effect.

I haven't used the Community-Edition of VS 2015, but in your project properties there should be something like Platform-Toolset (Confiugration Properties->General) and you should be able to change it to 120 if you install this toolset: https://www.microsoft.com/en-us/download/details.aspx?id=40760. Then it should compile as wished.

as Leadwerks does use a deffered renderer i could imagine one way: Render the voxel terrain into a texture buffer with multiple channels: normals, texture coords and position then do postprocessing on it and interpolate or blur each channel to smooth it out. Then apply the the blurred textures on a projected plane and manipulate the fragment values based on the smoothed channels.

while its representation is a 3d mesh or better a bunch of smaller 3d meshes it is bound to heightmap which is limited to 0..1 or 0..255 values depending on the internal format. Also a terrain system is a very performance hungry system in every engine so the culling, position calculation etc needs to be very optimized and if you can rotate, move or scale a terrain you always need add some cpu consuming matrix math to nearly each calculation. I agree that moving a terrain should be possible without much performance loss (it more or less just an offset addition), but scaling and rotating are too calculation heavy for such a system and can break the whole performance.

this was not possible in LE2 as well, you need to raise the terrain in general to a certain value and then carving your river out. [Edit:] Might be a nice feature. Raising the whole terrain by a certain amount.

If you have a standard license you should take a look into the headers and checkout the base Physicsdriver class. In theory it is possible in c++ to write its own physicsdriver and attach it. but there is no real detail how to do it.

It is aways a bad idea to compare float values directly lets take your exsample: value set in the Editor = 2: value sent to the shader = 2 / 255 = ~0.0078431372 calculation in the shader: 0.0078431372 * 255 = 1.9999 which is != 2 you may try something like: vec3 intcolor = round(floatcolor * 255.0); or you can make a comparison with a given tolerance.

Shader-Debugging is mostly done by mapping values or states to different output colors. You can try gdebugger (http://www.gremedy.com/) or NVidias NSight for Visual Studio. Otherwise the only way to get values is to write them to a rendertarget.

For me the fixed behaviour works perfectly.

I have made a small video shoing the problem: