Rastar

Well, sorry to say I won't be able to finish my project, and at its current stage there isn't even enough worth showing. I tried an implementation of the Geo Clipmap algorithm for rendering large terrains (read: element "earth" ;-) , see e.g. http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter02.html for a description), but next to the fact that I had to relearn some long forgotten C++ skills and venture into shader programming for the first time, I simply couldn't put enough time aside for this project. I will continue, however, and once it's done post it anyway to the Asset store. Good luck to all remaining participants!

Yes, but do create the instances in the Draw() call, or do you create them during initialization and store them in an array?

Is an instancing call expensive? I need many of those patches, can I instance them each frame update, or should I store the instances ( which would make the code less elegant)?

Ah, thanks, I wasn't aware of the Instance() member. But will this actually create a second vertex and index buffer? I like to draw the same set of vertices several times, since they're only the regular mesh to be displaced in the shader.

Somehow I can't find the right API calls for what I would like to do: 1) Define a couple of vertex and index buffers. These are used as generic patches for a displacement mapped terrain. I therefore only need 2D vecs, but of course 3D vecs are OK as well. 2) Draw these several times during a frame update, each with a different position and/or scale. The only place I could find to define vertex and index buffers is the Surface class. But if I use it as part of a model (created by Model::AddSurface() ) I don't know how to reuse the patches. If I try to use stand-alone Surfaces (Surface::Create() ) without adding them to a model, my program crashes. Is there a way to do this?

I haven't tried, but there is a TextureFormat integer for Cubemaps in the Texture class (static const int Cubemap) that you can pass to the Create method.

+1 I think this is a feature that is sorely missing, it would be so good to see the effect of scripts in-editor. Actually, a lot of the old "we need a plug-in system for Leadwerks" would be gone with this.

I can't remember that Josh said anything about the size, but I would bet that the maximum size of the heightmap will again be 4096x4096, and of course it will depend on your chosen scale (m/px) what the "real-world" size of your terrain will be. I think in the LE2 editor there was a maximum scale (that you probably could override in the project file), but your maximum terrain size will be constrained by floating point accuracy, z-fighting and jittering more than anything else. I am also a bit nervous about the vegetation thing since we haven't seen any screenshots so far with trees or foliage. But there's some time left until the end of the month...

Probably the only time you have to take the folder layout into account is when your developing both for Windows and OSX. You can't publish from Windows to OSX (only to Android), and on OSX you can only publish to iOS. But developing for Windows and OSX doesn't work out of the box, or I haven't found out. When I create a new class in VisualStudio, it is created in Projects/WIndows. I then remove it again from the project, move it in the file system to "Source" and "Add existing item.." But this is cumbersome, of course - I hope there is an easier way for this.

I am procedurally generating a model with several surfaces. Many of them have the same basic vertex structure and will be displacement mapped in the shader. Is it possible to reuse those surfaces? I would like to Draw them several times with different shader parameters.

Sheesh, got sick over the weekend and am only able to start right now. I've got an idea, but it was already a bigger bite than I can chew before that.. Anyways, still trying to get as far as possible.

Sorry, bumping this thread... I am procedurally creating a model with various surfaces and would prefer a wireframe model to better see if it's done right. Is there an API flag or something to do that?

Hi, how do your structure your source folders when developing for several platforms? By default, under Visual Studio and XCode, when you create new C++ classes they are created in the Project/Windows and Projects/MacOS folders. But many of them are (and should be) platform-independent, so I guess they should go under Source. However, I couldn't find a nice way to integrate that folder into a VS solution (it's possible under XCode, though). So: What's your preferred way of doing this?

Bending light? Am I Albert Einstein or what? No, actually I want to project some quantum-dynamic strings into hyperspace and then genetically modify their submolecular megatexture before transforming the space-time-fabric into super-entropic multi-convex Voronoi regions, silly! Or to say it in plain words: I am trying to use some third-party code for drawing skies and clouds...

I am trying to draw some stuff *before* and *after* everything else is rendered, but I have a hard time trying to do that: Anything that I do before World->Render() doesn't appear, I guess that method clears the buffer? Also, the camera and projection matrices aren't set at that time (I could compute them myself, though). I can't figure out a proper way for using DrawHooks. I have tried pivots and the camera as the wrapped entity, but both don't seem to receive the DrawHook call. If I use one of the other entities (e.g. Model::Box() ) - would my drawing code be rendered *in addition* or *instead of* the box drawing itself? Also, how could I influence the time when that object is rendered?

I need those two matrices from the Camera object. I found these undocumented members: projectioncameramatrix projectionmatrix So: I guess the latter one is the ProjectionMatrix I'm looking for? Then, is projectioncameramatrix the ModelView*Projection combined matrix? If so, where is the pure ModelView?

The only two places I could find where those macros are used was in Leadwerks.h I've renamed the macro to __OPENGL__ in the header and build definition files and now things seem to be working. I really think those macros should be renamed in the standard files, name clashes are too likely.

I'm playing around with a third-party library which defines an enum for various renderers, among them "OPENGL". That seems to clash with the OPENGL preprocessor macro in the standard project template. Is there a way to solve this? Can I rename the macro? And do a search&replace in the Leadwerks header file? It would probably be safer to call the LE macros, __OPENGL__, __OPENGLES__ etc.

Alright, I'm in. I'm gonna try something that I've been thinking about for a while which unfortunately is way above my head. Which means I most certainly won't finish... But at least I'll try to push myself and learn something along the way. Elements, ey? Love that topic!

This isn't in the command reference, but in the user guide http://www.leadwerks.com/werkspace/page/documentation/_/user-guide/scene-browser-r675

If you look at the docs (User Guide) it says Collision type This is the object's collision type. Collision types control what kinds of objects collide with one another. The following collisions will be recognized: Character : Character Character : Prop Character : Scene Character : Trigger (detection only, no physical reaction) Prop : Prop Prop : Scene Prop : Debris Debris : Scene So by using setCollisionType you're telling what kind your entity is, and these rules define if a collision will be registered when your entity intersects with another object.

This isn't useless - AABB intersection is an inexpensive check because the geometry is simple and no transformations have to be done. If it fails, the objects won't collide and you're done. If it succeeds you can continue doing (more expensive) checks using tighter, object-aligned volumes. I haven't used it, but looking at the docs I would guess that Entity::CollisionHook will let you know when two objects collide physically and react to that.

I've looked through the docs but couldn't find it: Is there an API call to set the RenderMode to Wireframe? Similar to what you can do in the editor via View->Render Mode ?

Should there, I agree, but maybe you can be do it yourself using Floor = Round(x-0.5) and Ceiling = Round(x+0.5)

That's awesome! Now, what would be really cool is if this could be combined with an imported heightmap. E.g., if you use real-life elevation data, their resolution is typically too low for games (for SRTM data it's 30m per pixel in the US and 90m worldwide). So you have to "enhance" them to make them visually interesting, like adding some Perlin/fractal noise and eroding some of it afterwards.