Rastar

Sorry guys, even if I risk boring you with my monologue... another screenshot. The heightmap resolution is too low for the foreground (4096 applied to 8000m) and the tessellation probably not optimal, so you see jaggies there, but I really like the crisp details in the background. But enough of this, I'll now have a look into optimizing the tessellation before I bother you again

This tessellation stuff is really interesting. The screenshot below was done using a simple heightmap+normalmap+colormap from World Machine and a modified version of the tessellation_example material (and of course shadmar's skybox!) applied to a scaled plane of 32x32 tris. It doesn't look spectacular because those are simple textures, and it performs like **** because this is a single mesh with no culling and LODs (every triangle side has a tessellation factor of 256, so that's a lot of vertices!), but it shows that there's a lot of potential in it. As I wrote, I would prefer to start from quads since that's more natural for terrain patches, but with adaptive tessellation guided by viewer distance, terrain features and an optional tessellation map, this could be used to render large terrains at excellent framerates.

Ah, sorry, I've overlooked that you were referring to the editor. Yes, I agree.

Well, it seems I got this working by setting layout (vertices = 4) out; in the control shader and layout (quads) in; in the evaluation shader. Wasn't aware of those functions (still new to tessellation..). On the other hand, I'm only working with a four vertex/two triangle patch right now that I am going to instance so that the patches can be frustum culled. Don't now what would happen if you start with a mesh that has more quads/polygons, since the vertex order is probably determined by the triangle indices? EDIT: Nah, this doesn't work. Of course, it only controls the patch size handed to the evaluation shader (which can be different to the input patch size). Also, the glTessCoord are barycentric with respect to that patch. So back to square zero: Is there a way to submit patches of four to the shaders?

There should be Camera:SetProjectionMode(), see here http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/camera/camerasetprojectionmode-r204

I would like to tessellate quadrilateral patches. I guess this currently isn't possible because the API doesn't provide for a means to generate quads, and probably the patch parameter is hard-coded to three, as in glPatchParameteri(GL_PATCH_VERTICES, 3) ? Or is there a way? If not, would it be possible to extend the API to add quads (e.g. by adding Surface::AddQuad() ) and set the patch parameter accordingly?

I am playing around with the tessellation shader. Is there a way to see the tessellation results in as a wireframe? It seems in the editor I always get the non-tesselated original meshes as wireframes. When running the game everything is shaded. I was using the (undocument) camera->SetDrawMode() in C++ / Leadwerks 3.0, but that isn't exposed to Lua.

I hadn't actually imported tose trees into Leadwerks 3.0, so I couldn't say how well it worked there, but just gave it a shot in Leadwerks 3.1. I first removed the two additional LOD levels since LE currently can't handle them (a feature sorely missing, if I may say so) and then resize them. I was able to assign the three materials by dragging them to their respective parts of the tree in the preview, though this was a bit fiddly for the trunk since you can't zoom in and it's quite thin. However, I still couldn't get a tree properly working in Leadwerks 3.1. I'm unable to get the leaf transparency working correctly, and the tree shadow isn't correct as well. In Leadwerks 3.0, shadmar supplied a leaf shader which discarded fragement below the cutoff which fixed that, but I couldn't get this working in Leadwerks 3.1. Now, I am actually not familiar with the intricacies of a deferred shader, so I might be doing something wrong. Also, the FPS is troubling me: If I put that tree on a 256x256 terrain, with a directional light and the skybox, I'm at about 70 fps (with medium lighting, 2x AA) on a GTS450.

But to my understanding, although the mobile versions will later be released for 3.1 they will still use their Leadwerks 3.0 (OpenGL ES 2) renderer (only the iPhone 5s and Android 4.3 upwards are using the new OpenGL ES 3). I guess it will be some time before we see this amazing renderer on the mobile versions..

Whoaaa, hang on, does that mean that hardware instancing is automatically taking place? Always, or as soon as gl_InstanceID is used in a shader for the object? I guess we really need some clarification here from Josh how this works!

Correction to the terrain level FPS: I forgot to turn off vsync (blush), seems this is on after a fresh install. I now get around 80 fps, which still is not overwhelming, though. Btw: Is there a code sample or something for the instanced rendering? I guess this needs special shader that use the uniform buffers, glInstanceId and stuff?

Congrats on releasing Leadwerks on Steam! It will be interesting to see where this takes the engine - judging from the comments, this move generates a lot of visiblity and attracts many people who haven't heard of Leadwerks before! I have played with it a little and have some questions: 1) Is there a shader "in the box" that I could use for trees? I tried the "if (outcolor.a < 0.5 discard);" check on the leaves, and it works a little but not fully, and the tree shadow is wrong? 2) Using the terrain from level 8 and putting in a couple of trees (like 10), a get a pretty low framerate (like 60 fps). Is the fps counter reliable? If yes, that would be troubling. 3) I can confirm the large terrain crash bug (see http://www.leadwerks.com/werkspace/topic/8032-steam-large-terrain-crash/). After you put anything in your scene (like a model) it cashes on start, just the terrain starts. 4) For the terrain level, it would be nice if there was a "fly-around" camera script.

About the Coming to Steam 1.6.14 on your landing page - at least every European will read that as "June 1st"...

I did that. Maybe its because the old and the new project had the same name? Edit: Tried to reproduce that but couldn't. I actually might have been editing old files in Visual Studio... Move along, nothing to see..

I have copied a complete Leadwerks project to another folder. Everything is working, except the Asset loader seems still to be looking for assets at the old location (has driven me crazy why LE wouldn't load my new shader ) So the (absolute) asset location must be somewhere in the project files, but I couldn't find it. The editor finds those files alright (well, I created them in the editor after all), but Shader::Load() seems to be looking at the old place. Where is the asset base folder defined?

In shadmar's code the skybox is created with coordinates (-0.5, 0.5, 0) etc., the camera has range 1000 so the box should be half of the camera range. I forgot about the parenting, so i don't actually have to do that. And my code means the skybox is scaled again every frame - no wonder i can't see it...

I set in the parent in the App:Start() method. But since I want to move I have have to adjust the skybox position every frame, so I movev those three calls to Update().

Leadwerks 3.1 will provide fallback shaders for older/less capable hardware. I don't know however, if those fallbacks will be compliant with the (current) OpenGL2 (ES) only or if there will be fallbacks for OpenGL 3.x as well. Since 3.1 will cost an upgrade fee, it might be worth waiting (if you can wait till then).

Noob alert... I still haven't grasped how to work with the render loop. As an example, I have integrated shadmar's skybox from http://www.leadwerks.com/werkspace/topic/7452-skybox-in-30-a-simple-example-with-shader/ into my C++ code. I put all that code in App::Start(), and everything works. Fine. Now, I would like to move the skybox with the camera. But when I move the lines sky->SetPosition(camera->GetPosition()); sky->Move(0,0,camera->GetRange().y-50); sky->SetScale(camera->GetRange().y*10); into the App::Update() method, the skybox isn't displayed, no matter if it's before or after world->Update() and world->Render(). Why is that? Is it because the buffer is cleared before the render loop? Why doesn't that affect stuff done in Start()? Do I have to use the DrawHook() to get the skybox into the render loop? If so, how can I affect the drawing order (or shouldn't I)? Sigh..

That's good news, thanks for the info!

Will those stages be available in the shader editor of 3.1? And, while I'm at it: Has anybody experience with using the tessellation shader for heightmap displaced terrains? I guess instead of sending the patches to the GPU they would be tessellated right there to decrease the amount of data that has to be sent over. Is there are noticeable performance benefit from that?

Attached are the map file (I had to zip it, the forum wouldn't let me upload a map file) and a modified App.cpp (it prints out the camera position and moves it faster). Put both in a new C++ project and move straight ahead. At around 1500 the orange box suddenly vanishes although it should still be in view. App.cpp start.zip

I would like to know what version 3.1 will bring for the iOS and Android platforms. Its focus, as we know, is Linux and the new OpenGL4 renderer, but that won't run on mobile devices. Is it possible to say which of the graphics improvement will run on mobile as well? As an example, the bug discussing project shadow performance http://www.leadwerks.com/werkspace/topic/7617-projected-shadow-performance-not-physics/ was closed with a reference to the upcoming dynamic lighting. But will that be available on mobile? Would it run with an acceptable frame rate? If not, then that bug shouldn't have been closed because licensees for the mobile platforms would be stuck with a half-ready solution. I'm not complaining or anything, I'd just like to know what to expect so I can plan accordingly.

I'm bumping this thread because I still think this is a bug. If not, please give me some hint what I should do differently.

Currently the terrain is limited to 1024x1024. When will larger terrain sizes be supported?