Rastar

While looking around in the Leadwerks header files, I noticed a Get/SetHDR() member in the camera class. That of course made me curious...: 1) Is it already possible to render to HDR buffer/textures? If so, is there also an option to define the tone mapping (or how is this mapped back to 8bits/channel)? 2) This raised a second question: Is Leadwerks able to do the rrendering in linear space? The default shaders obviously expect the colors to be in linear space (no gamma up/downscaling there). However, a typical texture will be provided in gamma space. Does Leadwerks do any conversions here? I know that there are hardware sampler states for that so that the GPU does the conversion automatically upon reading/writing. Are they used, or is it possible to activate that by configuration?

Yes, sorry for the confusion. I am not using the Leadwerks terrain, but my own terrain implementation, which yes, consists of mesh patches. And I like to move that with the camera since the mesh density is higher close to the entity's origin, so,it should be centered around the viewer. Think of moving a magnifying glass over a map.

I am not moving the Leadwerks terrain, this is just a entity with some meshes.

It's just the one call per game loop. And actually, I have the same drop when I parent my entity (and its children) directly to the camera. EDIT: Yes, I am actually moving the terrain. I don't think the number of vertices plays a role here, since they are in object space coordinates and not moved individually. No, something else must be updated during the SetPosition() call, since the position transformation itself should be pretty fast.

I am playing around with a custom terrain once again. The terrain has a number of patches parented to it, depending on the terrain size these can be between a few dozen and several hundred. They are all directly parented to the terrain, no sub-hierarchy. I have added a hook void CameraPositionHook(Entity* entity) { MT::Terrain * terrain = static_cast<MT::Terrain*>(entity); Camera* camera = terrain->GetCamera(); Vec3 position = camera->position; position.y = 0; if (camera) terrain->SetPosition(position); } which I add as an UpdateWorldHook to the terrain, and the SetPosition() call causes the observed rate drop.

I would like to move an entity together with the camera. Since I don't want it to rotate with the camera, I just called ent->SetPosition(camera->position + offset) every frame. However, that seems to be really expensive - doing so gives me a framerate drop from 100-110 down to 50-60 (in Debug). Is Leadwerks doing some expensive calculations during this call? EDIT: OK, the frame rate drop seems to depend on the number of children that my entity has, so I guess the engine goes down the tree and recalculates the transform? However, that still seems to be too costly.

Since you're saying "for school": You can use Visual Studio Professional for free as part of Microsoft's Dreamspark program.

I know I'm getting on everybody's nerves (at least Josh's) but... API for editor plugins, pretty please! As a teaser: Two days ago, Side Effects released a very affordable Indie version of Houdini. Also of the Houdini engine, which has an API to be integrated into other applications, and API-wise it shouldn't be too hard to integrate that with Leadwerks - if only there was an API for that... And then you could procedurally generate geometry, create road networks etcpp. Pretty please...

If you open those files inside Leadwerks, it will parse them and correctly categorize the shader parts (vertex, fragment etc)

Thanks for checking! I have just watched that video on another computer and my iPad, and I can't see the described artifacts either! However, I can still clearly see them on my PC either when playing the video or running the map inside Leadwerks. WTF? I tried taking a screenshot but that doesn't show them as well. Must be some issue with my hardware or driver.

After some time off I created a new project today (C++ standlone build 3.2). I just build it and ran it with the start.map to see if everything was fine, bt I got heavy artifacts when moving the camera: If you look closely you red borders around the bottom orange box, the edges of the concrete box flickering and the edges of the concrete box getting a yellow tint, the sides changing with camera direction. Bug, feature, my mistake?

True. But the means for many of the things that you describe are already in place. You already *can* write post processing shaders, for example (of course you must know how). But you can't write plugins or something similar right now. The things I had in mind when I asked that question were a road generation tool, procedural placement of vegetation and a custom material/shader editor. I just think the main focus for a one-man show like this should be to enable its community whatever they want to do - that's the only way you can make up for other engines' man power. But I know that this discussion is leading nowhere...

Too bad - that basically means there is no way to procedurally modify your levels at design time. I think that should be high on the priority list, either by adding Save() methods to the Leadwerks API, or by allowing Lua scripts to run in the editor.

Bumping this thread since I'm reallyreally interested in an answer...

I would like to manipulate several Leadwerks assets outside the editor. The API provides all necessary functionality, except saving. I've seen that there is a Save() method e.g. in Map and Texture, but they are commented out. Also, the Object base class has methods for serializing/deserializing which require a Stream (and I'm unsure how to correctly create that). Long story short: Is there currently a way to save such objects (as a first step I would need materials and the map itself)? @Josh: If not, could you add that?

Well, Rick seems to be quite proficient in it :-) Smaller things I might be able to do as well.

What exactly is the issue of setting the OpenGL contexts? That shouldn't be language-dependent. By the way, I found that using a library like http://www.glfw.org makes this process rather painless, cross-platform (and C++ based). There, setting the initial context for OpenGL requires a glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 2); glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE); glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE); So you have to set the profile to 3.2 and forward compatible, which was a little counter-intuitive to me :-) As a side notice, I find the statement "I don't have time for that" a little...nonchalant. OSX users have purchased/preordered the upgrade like everyone else, and I guess that "contract" should be fulfilled even if other things seem to be more in focus right now.

Again, I'm a complete modeling legasthenic, so I don't know what it takes to "support morphing", but OpenGEX supports morph targets.

Well, I'm on unsafe ground here because I have next to no modeling experience. From what I understand, the other formats (fbx included) are somewhat unreliable, sometimes due to changes between versions, sometimes due to flaky exporters. It probably depends on what the reasoning behind the Blender exporter is if looking at this makes sense, I just noticed that your description sounded like your planning something similar and thought this could save some effort.

About that Blender plugin: You might consider using OpenGEX. It is an open format for exporting models from modeling tools and importing them into game engines (yes, designed by the owner of the C4 engine, but that shouldn't rule it out). It was born out of the frustrations that model conversions for the proprietary formats cause (especiallly for animated models), and the failure of Collada to solve this. Plugins for 3DS Max and Maya are already available (open sourced), Blender will be soon. The task would then be to convert that into mdl format, which shouldn't be too hard.

The LE3 displacement shader already tessellates, but probably the algorithm and its configurability could be improved upon (as Josh stated above). And yeah, that tessellated terrain is nice, but it's a pretty complicated algorithm (described in Shader X7), since they first render a point cloud in a first pass to get info on the terrain structure, and then calculate the tessellation factors in a second pass.

Actually - no, I don't (maybe shadmar and klepto know something?) It might be better to start with a forward renderer to learn shader programming, because everything is right in front of your eyes, and playing around with different light types, lighting models etc is possible. I started digging into shaders with Leadwerks 3.0 (which has a forward renderer), and that was helpful at least for me. And it might be easier to understand what is going on in a deferred renderer if you have done everything for yourself first.

It's not working for two reasons: 1) All those special variables for vertex normal, light position, transformation matrices are not part of GLSL. They are passed in by name by the engine, and every engine has its own naming convention. If you have a look in a Leadwerks shader, the uniforms there have names like vertex_normal, entity_matrix ('M' of the model-view-perspective transform) and projectioncameramatrix (the 'VP'). So the variables you're using in your code don't carry any values. But even if you used the Leadwerks variables, this concrete shader wouldn't work in Leadwerks 3.1 because 2) it's written for a forward renderer, and Leadwerks 3.1 has a a deferred renderer. In a deferred renderer, the lighting calculations (here the diffuse shading with the NdotL term) are done for you behind the scenes. The shader's main job is to fill the fragData G buffers for diffuse color, normal, emission etc. that the engine needs for its calculations.

I faintly remember Shadmar doing something like this in the early 3.0 days..

I am not too familiar with the various raw formats (I think every manufacturer has one or even several variants containing some specific metadata). And I don't know if Leadwerks is able to skip this metadata. A "really raw" RAW file for heightmap import contains just the pixel values (only one channel) as floating point values (preferably is 16bit format, or two bytes per pixels). Maybe you can convert the file using Photoshop or a similar tool? Or you could write a little conversion routine.