klepto2

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:

Just because it has always been this way doens't mean it is not a bug. In my opinion rotating/moving an object should never result in doing something else then rotating/moving an object.

If that is the case then gizmos etc should be locked while being in editmode.

Hi, if you sculpt or paint a terrain and then move/create/ rotate an entity in the Perspective-window via the gizmos, the terrain edit mode is still active and you edit the terrain without wanting it. Also happens if you drag and drop entities from the asset window. klepto2

This will improve the workshop a lot. How about a way to choose on a per project basis which workshop items you want to have in the project. This way you can handle updates globally (on the user machine) but seperate from your current project. I don't want to have all workshop items available in my projects espeacially if i just want to test something out. You can replicate a local version of the steam - workshop on the user machine.

I know that these gl_* matrices are obsolete. To make my question more clear: What are the equal terms in Leadwerks? cameramatrix = ?, etc. Or if not available, how to constuct or pass them to the Leadwerks Shader system? Its hard to find information about this if you don't know exactly what the leadwerks matrizes are equal to in other languages.

Hi, i'm currently trying to translate a shader which is written in glsl 1.5 and i have some trouble to find the correct matrix values in Leadwerks: vec4 getWorldPosition(vec2 coord) { vec3 view = getViewPosition(coord); vec4 world = vec4(view.x,view.y,-view.z,1.0); world = gl_ModelViewMatrixTranspose*world+gl_ModelViewMatrixInverse[3]; return world; } vec4 getCamPosition(vec2 coord) { vec3 view = getViewPosition(coord); vec4 world = vec4(view.x,view.y,-view.z,1.0); return gl_ModelViewMatrixTranspose*world; } gl_ModelViewProjectionMatrix I know i can use transpose() and inverse() but what are gl_ModelViewMatrix and gl_ModelViewProjectionMatrix in Leadwerks shader system?

Native integration of DAZ models is not possible. There is no direct SDK to use and while the models are really nice they are not useable by any 3d Engine in the daz format (to much polygons, morph algorithms are not available and much more). The only way to use them is to use the provided daz tools to reduce polygons and export them as fbx which already works with leadwerks.

If i understand you correctly you made some kind of simple keyframe animation? If yes, Leadwerks will not be able to use it. The animationsystem in Leadwerks is made for IK (bone/rigged) animations and so only those are supported.

As Rick said, Leadwerks uses OpenGl which uses GLSL. GLSL is much different than HLSL. There are converters for this, but they are not really good and don't work in many cases. So this Editor is unfortunatly not usable in LE.

So the company name is inspired by a brewery in Siegen,Germany or the one in USA?

0.5 seconds^^

As you're using c++ you should have access to the lower members of the model. There should be a vector (or smth. like that) containing the surfaces. In theory you should remove them from there and then a call of model->Update should do the rest. I can't tell you the correct member in the model class, as i have no access to the headers at work, but i would suggest to look into the headers yourself. I found a lot of knowledge about the engine-internals just by studying the headers.