Rastar

The shader has a cutoff value of 0.5 hard-coded in the fragment shader. I don't have Leadwerks access right now, but it should read something like if (color.a < 0.5) discard; You could lower that value to see if it gives better results (maybe first saving a copy of the shader). Also, do the leaf textures use color bleed, meaning the leaf edges are smeared or surrounded by some green color? That helps with some artifacts you might get with alpha testing and mipmapping.

I don't know the latest status on this, but: Josh was planning to do an OpenGL 3.3 fallback on Linux (not on Windows) due to lacking driver support for OpenGL4+ on some systems. http://www.leadwerks.com/werkspace/topic/9229-installing-leadwerks-for-linux/page__hl__fallback So you're GT240 might fall back to 3.3 under Linux (but not under Windows), while the 3.2 driver isn't supported.

Bumping this - I'd really like to have an answer for this. Am I missing a method call or something, is this generally expected behavior, is there some problem in the way Leadwerks handles the scene tree...?

Yes, as detailed above I get basically the same result with boxes and (empty) models. Pivots are a little faster, but I guess no draw calls have to be issued for them.

Well, this helps, but it does so by destroying the entity.

OK, I did some more tests, this time not with confusing terrain stuff... It seems it is not really the call to SetPosition(), but rather the number of objects that causes the slowdown. However, I still don't really understand why. Attached is a little App that 1) creates a pivot 2) creates a configurable amount of boxes/meshes/pivots (boxCount in line 40) and parents them to the pivot 3) set the pivot's position every game loop (line 97). Running in debug mode I get ~135 fps for 0 children ~105 fps for 100 children ~65-75 fps for 250 children ~45-60 fps for 500 children Results for the three entity types are similar. There is nothing else in the scene, not even a light. I wouldn't expect that sort of slowdown - am I doing something principally wrong? Does the scene tree not like flat and wide structures? Thanks for any hints! App.cpp

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.

You will probably have to recenter everything to the origin (read: the player) anyway for an "endless" terrain, because beyond a certain distance (say, 16000) physics will get unreliable due to floating point inaccuracies.

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.