Rastar

You could also try http://www.hptware.co.uk/forester.php. It's not free, but very affordable, and the poly count is fairly low.

Thanks a bunch

After some crunch time at work and a bit of vacation it's about time to continue with my "me too" attempts at using tessellation. Before proceeding with my terrain implementation I'd first like to give a bit of information about the new tessellation functionality in OpenGL. Again, the usual disclaimer: I'm just learning that stuff as well, so this will be basic explanations. Introduction Together with the subsequent geometry shader, tessellation is one of the stages where vertices can be created (or discarded). It operates on patches, i.e. sets of vertices (usually triangles or quads). When the application issues the draw call, it can specify the patch size, e.g. by calling glPatchParameteri(GL_PATCH_VERTICES​, 3​); This informs OpenGL that three subsequent vertices are to be considered a patch. The tessellation shader then subdivides the patch into additional triangles. Leadwerks currently only uses triangle tessellation, so that's what I'll consider here, but especially quad tessellation (patches of size four) is of interest as well (suggestion filed). An OpenGL4 tessellation shader actually consists of three separate stages (as in DirectX11, by the way), one fixed and two programmable: The first (programmable) stage is the tessellation control shader. Its main job is to specify the tessellation factors, ie how often the patch should be subdivided. The second (fixed) stage actually creates the additional vertices. The third (programmable) stage, the evaluation shader, provides the opportunity to process the vertices and their attributes before they are passed to the fragment stage. Variable names Before actually using the tessellation shader for anything meaningful, I'd first like to describe a pass-through shader: a tessellation stage that actually does nothing (apart from using up valuable resources...). In principle, the vertex and fragment shaders can be left as is when adding a tessellation shader. However, care must be taken with the variable names for data that is passed between stages. For example, a typical Leadwerks vertex shader might have the following input: in vec4 vertex_color; in vec2 vertex_texcoords0; and the corresponding output out vec4 vColor; out vec2 vTexCoords0; which is passed to the fragment shader by name in vec2 vTexCoords0; in vec4 vColor; Now, if you put in a tessellation shader, vColor and vTexCoords0 will be passed into the control shader, and you can't directly write back to those variables. So, you might have an intermediate variable pair out vec2 cTexCoords0[]; out vec4 cColor[]; (those are arrays because the control shader operates on the whole patch) and then in the evaluation shader define //Inputs in vec2 cTexCoords0[]; in vec4 cColor[]; //Outputs out vec2 vTexCoords0; out vec4 vColor; so you're back to the original variable names that the fragment shader expects. By the way, there is one thing you might want to change in the vertex shader: You usually pass vertices in world space to the tessellation, not camera space. So, instead of the usual gl_Position = projectioncameramatrix * ex_vertexposition; in the vertex shader, you would rather do a simple gl_Position = ex_vertexposition; and do the vertex transformation later on in the evaluation shader. Control shader The tessellation control shader starts with a layout definition layout(vertices = 3) out; This defines the size of the patch that is submitted to the tessellation stage. While you will normally find a value of three here, it doesn't have to be that way - you could define a patch size of four and fill in the data for the missing vertex right in the control shader. Now, since we're heading for a pass-through shader, the vertex attributes should be handed down to the next stage unmodified: cTexCoords0[gl_InvocationID] = vTexCoords0[gl_InvocationID]; cColor[gl_InvocationID] = vColor[gl_InvocationID]; and so on for the other interpolators. This needs a bit of explanation: First, as mentioned, the control shader has access to the whole patch data, so the attributes are defined as arrays rather than single values. Since the patch size is three, cColor[] for example will have the values cColor[0], cColor[1] and cColor[2], storing the colors for all three patch vertices. The control shader is executed once per vertex in the patch (before everything is passed to the next stage), and the predefined variable gl_InvocationID gives the current execution count (so it runs from 0 to 2). Now to the most important thing in the control stage: defining values for gl_TessLevelInner[] and gl_TessLevelOuter[] - the tessellation factors. They define how often the patch's edge (gl_TessLevelOuter) and interior (gl_TessLevelInner) should be subdivided. It depends on the patch type (triangle, quad) how many tessellation factors there are; for a triangle, there are one inner factor and three outer ones. I guess a picture is worth a thousand words: In this image, the triangle has an inner tessellation factor gl_TessLevelInner[0] of 3 (you need three small triangle to cross the large one), while glTessLevelOuter[0], glTessLevelOuter[1] and glTessLevelOuter[2] are all 2 (every edge is divided into two segments). Now, for a pass-through shader all tessellation factors should be equal to one, leaving the original trangle unharmed: if (gl_InvocationID==0) { gl_TessLevelInner[0] = 1.0; gl_TessLevelOuter[0] = 1.0; gl_TessLevelOuter[1] = 1.0; gl_TessLevelOuter[2] = 1.0; } The if statement in the beginning makes sure that we calculate those factors only once for the patch (remember: the whole control shader is executed for every vertex in the patch). And that's it for the (pass-through) control shader! This definition will then be send to the fixed tessellation stage which takes your recipe and creates many shiny new triangles (or in our case: not). Next time I'll go from there and describe the evaluation shader. So long! By the way: The title image is one of my hasty smartphone snapshots taken while going cycling on the Isle of Mallorca. This is the road to Sa Calobra, steeply winding down to the sea where you can relax in one of those nice cafés - after which you unfortunately have to ride back up again...

Oh, sorry, was assuming 3.1. For 3.0 you will need a shader with a correct alphatest. I can't find the link to shadmar's 3.0 tree shader. Basically, in your fragment shader you will need the line if (outcolor.a < 0.5) discard; and a "Solid" blend mode (I guess you're using "Alpha" right now?)

Try assigning an alphamask shadow shader (Shader->Model->shadow->shadow+alphamask.shader) in the material editor.

Actually, there has been something similar for Leadwerks 2.x (I think it was simply called "the Leadwerks community project). I wasn't part of the team at the time, but looking from the outside I think both sides were benefiting from it, and it seemed to influence Josh's priority list. So, in short: I actually think this is a very good idea!

Well, those shadows fade out when I move some 20 units or so away - that's a pretty short range for an (inifinite) directional light... it definitely has to go further, and it has to be adjustable.

Sorry for necroing an old thread, but... has this been solved/answered? The range setting on the lights tab doesn't do anything (and by the way, if you close and reopen Leadwerks, that range is set back to -150/150, even if I save my map before closing). Also, I actually don't understand what those values mean, especially the first one - is that the range of objects behind the camera that cast shadows?

Maybe try to delete *everything* include Leadwerks' .meta files, fbm folders etc. As wrote, for me it suddenly worked (bu manual assignment), but i don't know what was different.

Mmmh, I started over by deleting everything and copying the files freshly into the Leadwerks folder. The automatic assignment didn't work for me, but that be because the file paths are different (at least the DAE files reference textures in an "images" folder, but the the distribution stores them in a "textures" folder that I copied over). Now it's working , but I don't think I've done anything different than the first time. Anyway, thanks for your help!

As a 3D modeling analphabet I need a little help here... I am trying to import some tree models from pure3D's Vegetation Starter Pack. As usual for trees, they have at least two materials (for trnk and leaves), sometimes more. Now, assigning those two materials for the beeches in the pack (using drag 'n' drop in the model editor) works fine, but e.g. fails for the oaks: any material will always be applied to the whole model. What puzzles me is that those trees look similar in structure when viewed in UltimateUnwrap3D, and I don't really know what Leadwerks is looking for to identify a surface. I *could* export the materials/groups as separate meshes, but I don't really want to do that. Any ideas what I might be doing wrong or can change to make things work?

A bit of documentation on this would be helpful, I find this bit confusing as well. E.g., I have to assign a alphamask shadow shader to my trees so they correctly cast shadows, and I actually don't have a clue why.

Am on vacation right now, with only very shaky internet access and a Macbook (so no 3.1). Will do the next chapter some time next week, but won't be interesting for the likes of you I am going to describe a tessellation pass-through shader.

I actually haven't looked too deeply at the Leadwerks terrain system, but this is "just a bit of shader magic". Quickly scanning the terrain texture shader, it seems there are certain thresholds for the texture blending, resulting in those hard edges. So tweaking the shader might give what you want. You could also try and play with the "transition" slider on the material layer page, maybe this improves things towards your goal.

Actually, I think this is looking much better and more realistic than the typical texture blending using alpha values. I mean, for ground structures such as this you have small height differences that determine which material is on top: The sand will fill the lower parts of the rocks and be completely absent at the top, and not gradually shine through the rock texture. For example, there is a very popular terrain add-on for the "he-who-must-not.be-named" engine that specifically uses heightmaps for terrain textures to achieve this effect. EDIT: By the way, now "mrstralberg", Sir? Being more formal these days ;-) ? EDIT2: There was a post where Josh discussed this http://www.leadwerks.com/werkspace/topic/7196-terrain-texture-with-blend-pattern-in-alpha/page__hl__alpha

If you specify that variable as "in vec2" it is supposed to be a vertex attribute, ie have a different value per vertex. However, the Shader:SetXY() methods set shader uniforms. So I guess, in your case you should define that as uniform vec2 my_offset;

The fragment shader might work on pixels, but everything before it works on vertices. You define vertex colors in your modeling program, and they are interpolated for the fragments by the rasterizer, just like everything else. I don't think LE should provide tools for vertex coloring, that's really the domain of DCC tools.

Not sure if I'm misunderstanding you, but that should be possible already. Leadwerks passes the vertex color already go the shader (uniform vec4 vertex_color). By default it is mixed into the diffuse color, but the shader could use it for something else. Of course, you would have to define the vertex colors for your model in your modeling program first.

..and just to be sure.. in your sample code you write "self.enity" instead of "self.entity" (though that might just be in your post and not your code)

If a method isn't supported in Lua, the compiler complains that you're trying to access non-existing property XY. If you get a nil mat then the call was successful, but the entity doesn't have a material. Are you sure you're calling GetMaterial() on the correct entity? self.entity will be the scene object to which the script is assigned, is that the correct one? By the way, I think calling that method will change the shadow casting for all models that use that material (even for the non-dead aliens). So maybe you should create a "Dead alien material" and assign that using SetMaterial().

Just as an additional illustration: Using a (mean and inefficient) hack in the control shader, I got quad tessellation. Compare Triangle tessellation to Quad tessellation (both using fractional_odd_spacing). At least for my purposes, I would definitely prefer the more regular structure of the latter.

In your project, there is a folder "Shaders/Model". There is a simple Shader called "diffuse.shader" which only uses a diffuse map. In your case, with three outputs, you would probably use "diffuse+normal+specular.shader". I just wanted to make sure you're using one of those (open your material in the editor and have a look at the "Shaders" tab).

Ah, OK, thanks for the explanation. And how come the information tab switches from RGB to RGBA if I check that box?

Sounds like a great idea. Several materials would probably have a similar noise texture (grass, coarse sand, granite surfaces, ...). But texturing is still some blood, sweat and tears away....

@ScrotieFlapWack: Probably a silly question, but just to be sure...: You are using them with a corresponding shader, right (e.g. diffuse+normal.shader)? If yes: How did you generate them? You should see a visual difference already in the material editor (might have to hit "Save" for this).