Rastar

I'm a bit mixed about this myself. Right now, the Leadwerks pages are the "one-stop shopping mall" for information, and this would get more complicated with an external wiki. Especially for longer articles you would have to decide if they should go in the official tutorial section or in the unofficial wiki, and you'd have to places to look for answers to your questions. On the other hand, such things are very fragile. To generate an avalanche effect it must be easy to find information and easy to put it in. The current pages don't meet that requirement. Also, there are two additional benefits of external pages: If there are several web sites about the engine and an active external community it shows that there is impetus behind Leadwerks that goes beyond its creator. And, of course, we would be a little more free in what we can write.

But those are the near and far ranges, evaluated relative to the current camera position, aren't they? So if I have a far range of 1000 and the camera is at 1000, I should be able to see objects up to 2000, correct? If I set the far range to 1000, my plane vanishes when the camera reaches about 1500 (so I guess that's the default). With a far range of 1500, it vanishes around 2000, with a far range of 2000 it doesn't get culled. I still don't understand that behavior.

After not finding the problem with my clipmap terrain getting culled once I move the camera beyond about 1500 units from the origin, I did the following test: Create a new project, open the start.map, delete the blue cube and scale the orange plane by 100 in the x and z directions. Move it to (0,0,1800). Then run the project and move the camera towards the plane. Once you're getting to about 1500 units, the plane vanishes. So either this is a regular effect, then I'd like to know how to get around it (I need much larger distances). Or it is a bug, or there is some general culling call in the engine or something which I need to adapt.

No, no one has Beta access up to now, so we're describing the current pipeline. However, I don't think the workflow is going to change, rather that there will be an additonal project/platform for Linux. Josh mentioned he will be targeting CodeBlocks for the Linux project.

OK then, I'll set something up. Gonna take a couple of days. I would suggest we have more than one administrator (also regarding the backup issue) so please PM me if you're interested.

Yes,you can use external models (at the moment only fbx I think, but that might change with the Linux plugin). even the old LE2 models should work after renaming the extensin. You can build the entire game in C++. When creatimng a new game, LE3 generates up to four sub-project (VS 2010 for Windows, XCode for Mac OOs and iOS, Eclipse ADT for Android) where you keep the platform specific stuff. Also, there is a top-level Source folder for shared code. To compile for a different platform you simply run the build in the corresponding project (you might have to "publish" the game from The LE editor first). This stuff is working very well.

I know, but that format doesn't suit the smaller bits and pieces very well. So, I gather a community-made unofficial wiki would be the preferred choice. However, the feedback has been a bit feeble up to now so I wonder if there is enough interest?

In my humble opinion, a community wiki for Leadwerks 3 is sorely missing. While there is a lot of great information here in the forum and in the documentation section, it is often scattered over many threads, and the search function isn't of great help. Also, I think people are more willing to write a short paragraph in a wiki about some new revelation they had rather than open a thread in the forums (looks a bit like boasting somehow ). So: I call upon creating a new Leadwerks wiki! I guess there would be two options: 1) Official wiki provided by Josh. AFAIK there was one for LE2 that was closed down at some point, can't remember the reason, though. 2) An unofficial wiki on some remote page. Would have the benefit that Josh does not have to somehow feel responsible for its content. I would volunteer to set it up and even pay for the hosting if there is no suitable free solution. Whichever version it will be, I think this would be of great value to the community and take some of the documentation burden off Josh's shoulders. What do you think? Anybody in? @Josh: Which solution would you prefer?

I understand, but adding that call to the RectangleTesselator doesn't change the behavior, at least on my end. Just wanted To say: I really appreciate your support, I know you have a load of stuff on your plate and more urgent business to do than fixing other people's code...

Whoaa, I wasn't aware of that. I noticed your texturing approach looked similar to their structure for the heightmap base mesh. I am heading for a very large terrain, and their approach seemed very interesting to me, especially with the method for compressing the height data. If I can use that with the built-in terrain I would be more than happy! I've tried the various UpdateAABB() calls, but that doesn't seem to help.

Well, here is my code (don't be too harsh, I'm in the process of relearning C++ ... ;-) I am trying an implementation of the geometric clipmap method as described here http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter02.html. It uses a series of concentric mesh rings with decreasing LOD, each ring assembled from several patches. As described, run forward using "W" to about 1500 units and all patches vanish. Thanks!

No, currently they are not parented. Do they have to be? I have a set of 7 different patch types (Models) which I instance, scale and position to create the "mesh puzzle" seen in the screenshot.

I know, and that means they're not guaranteed to work and might not be fixed. Still, I think there's value in reporting those isues - which caring developer wouldn't want his code to be without flaw ;-)

Mmmh, no, both Update() nethods don't seem to help.

I call patch->UpdateAABB(Entity::LocalAABB|Entity::GlobalAABB); after creating and/or scaling a patch. But a question: I am displacing many of those patches a fair amaount after creating them. Do I have to call UpdateAABB(Entity::GlobalAABB) after moving them?

I am laying out a large array of mesh patches that will be heightmap displaced in the shader. It's working fine, except that when the camera moves a certain distance from the origin (about 1500 units or so) all meshes suddenly vanish. Moving a little back they appear again. This is independent of the camera's clipping planes. Bug or feature? If feature: Is there a way around this? There... ...and gone. The meshes in the back are gone as well.

I am using Context::DrawStats with the "extra" parameter set to true. This gives additional parameters on screen, however the values for polygons, batches and draw calls are all zero (see screenshot). Do I have to do something special to get those, or is this not fully implemented?

As an info and warning, I had problems with running Leadwerks after updating to the latest Nvidia driver (327.23). Leadwerks (and projects started from Visual Studio) crashed with an access violation exception (the Leadwerks dialog said "OpenGL 210 and GLSL 120 not supported". Cleaning the project and reinstalling Leadwerks didn't help. After rolling back to driver 320.49 everything worked fine again.

After calling camera->SetDrawMode(DRAW_WIREFRAME) everything is rendered as a wireframe, however the camera's colordrawmode property is still set to 4 (DRAW_SOLID).

Just stumbled across this in the header files, and since no one answered I'm gonna do that myself in case somebody else needs it ;-) if you set camera->SetDrawMode(DRAW_WIREFRAME) every is rendered as, well, a wireframe.

So I continue with my shader questions... ;-) It seems the lightcolor uniform only contains values if lightposition has been used at least once. So if I return gl_FragColor = lightcolor[0]; from the fragment shader it is empty if I didnt't call the position before, but if I insert lightposition[1]; somewhere before (doesn't even have to index the same light) it works fine. Is there any reason for that?

Yes, I saw that line. But where are the values coming from (in terms of the editor)? It's not the diffuse color, since there is a separate materialcolordiffuse uniform for that.

I have finally made the leap and started to get in to shader programming. While this is a complex topic in itself, it is made even harder for a beginner like me to understand the interaction with Leadwerks itself, specifically which data is passed into the shaders by naming convention. Some information can be guessed by looking into the supplied shaders, but many open questions remain. So my request would be to add a section on shader programming in to the docs. Doesn't have to contain thins like "How do I create a rim lighting?" but rather the Leadwerks specific stuff. One example (and my concrete question): It seems there is a color encoded in the last column of the entity matrix - which one is it?

Same here (Mac, too). Also, I can see new terrain classes in the API, but no terrain tab or icon in the editor.

For some reason I still can't see the terrain tab in the editor and work with terrains. But I noticed there are a couple of new classes in the API, namely Terrain TerrainPatch TerrainCache TerrainLayer Some documentation and code samples would be nice to show what can (or cannot) be done via the API.