Ma-Shell

Yes, they are meant to be vec3. Given, your method has the following inputs: <code>unsigned int x, unsigned int y, float map[]</code> When I wrote f(x,y), I meant map evaluated for the given coordinates, so they correspond to your center_X - variables. i.e.: f(x,y) = map[current_index] f(x-1,y) = center_l f(x+1,y) = center_r f(x,y-1) = center_u f(x,y+1) = center_d This means, you can calculate the left, right, up, down vectors as: Vec3 Left = Vec3(x-1, y, center_l); Vec3 Right = Vec3(x+1, y, center_r); Vec3 Up = Vec3(x, y-1, center_u); Vec3 Down = Vec3(x, y+1, center_d); However, you don't need to define these, as you can see in my post, you can directly represent the results: You would end up with: Vec3 normal = Vec3(2*(center_r-center_l), 2*(center_d-center_u), -4).Normalize(); You can see, this actually ends up the same as what you wrote in your initial post (after it is normalized) only with y and z flipped, which is my fault for assuming, z was the height-coordinate. So in conclusion: What you are doing in your initial post is exactly the result of the cross-product. If you actually DO use the cross-product instead of what you did there, you don't gain anything, but instead you only lose efficiency.

You are right, this can be done by using the crossproduct. For calculating the normal of the point p with coordinates [x; y; f(x,y)], (whereas f(x,y) is the height-value at point x, y) the following four neighbouring points are of interest: Left: l [x-1; y; f(x-1, y)] Right: r [x+1; y; f(x+1, y)] Up: u [x; y-1; f(x, y-1)] Down: d [x; y+1; f(x, y+1)] This means, you have the following four vectors: l -> p: lp [x-(x-1), y-y, f(x,y)-f(x-1,y)] = [1; 0; f(x,y)-f(x-1,y)] p -> r: pr [(x+1)-x, y-y, f(x+1,y)-f(x,y)] = [1; 0; f(x+1,y)-f(x,y)] u -> p: up [x-x, y-(y-1), f(x,y)-f(x,y-1)] = [0; 1; f(x,y)-f(x,y-1)] p -> d: pd [x-x; (y+1)-y; f(x,y+1)-f(x,y)] = [0; 1; f(x,y+1)-f(x,y)] You can build the four cross-products: up x lp, up x pr, pd x lp, pd x pr (I used the right-hand-rule to determine which directions to take the crossproduct) and then take their average for your normal. Since every vector has one component 1 and one 0, the crossproducts are fairly simple: up x lp: [f(x,y)-f(x-1,y); f(x,y)-f(x,y-1); -1] up x pr: [f(x+1,y)-f(x,y); f(x,y)-f(x,y-1); -1] pd x lp: [f(x,y)-f(x-1,y); f(x,y+1)-f(x,y); -1] pd x pr: [f(x+1,y)-f(x,y); f(x,y+1)-f(x,y); -1] Adding these four vectors and then normalizing them should yield your normal. EDIT: You can also just take the two vectors u -> d: ud [x-x; (y+1)-(y-1); f(x,y+1)-f(x,y-1)] = [0; 2; f(x,y+1)-f(x,y-1)] l -> r: lr [(x+1)-(x-1); y-y; f(x+1,y)-f(x-1,y)] = [2; 0; f(x+1,y)-f(x-1,y)] And their crossproduct: ud x lr = [2(f(x+1,y)-f(x-1,y)); 2(f(x,y+1)-f(x,y-1)); -4] And normalize that. Doing so, yields a less accurate version but might be faster, since you only need to calculate one vector instead of four.

It's far from perfect but I wrote a simple Python 3 - script which parses "API-Reference_Object_Entity_SetPosition.xml" (which has to be in the current directory) and exports it as HTML ("out.html") and LaTex ("out.tex"). You will need a LaTex-Compiler (e.g. https://miktex.org/download) to generate a pdf out of this LaTex-file. generate_docu.py.txt

I think, what you're trying to do is called texture splatting. Take a look at this link: http://www.gamasutra.com/blogs/AndreyMishkinis/20130716/196339/Advanced_Terrain_Texture_Splatting.php The shader should give you access to the normals and positions, so you should be able to take these to determine height and slope.

The material itself has some functions to set shader-uniforms (sadly the function-name does not always reflect this, but e.g. these SetFloat, SetVec2, ... are for setting uniforms) I don't really know about these types of buffers for shaders but if you can represent your buffer as a texture, you can do the following: C: m->GetSurface(0)->GetMaterial()->SetTexture("Materials/Developer/window.tex", 3); This will bind the given texture to texture-slot 3 of m's material. Fragment Shader: uniform sampler2D texture3; ... outcolor = texture(texture3, vTexCoords); I haven't tried whether it is possible to access it from the geometry shader, though. I just tried it in the geometry shader and it works there, as well.

Actually you can access the forum in HTTPS, as well. But most links have "http://" in their "href"-field, and thus will route you to the unencrypted pages.

By default it won't change the physics shape. It is, however possible to send the output of the geometry shader to an output stream and then access it from the cpu. I have never done such a thing thoug and don't know how exactly that works, but it should be possible to generate the physics-shape from it. Some reading: https://www.khronos.org/opengl/wiki/Transform_Feedback https://www.khronos.org/opengl/wiki/Geometry_Shader#Output_streams

http://www.leadwerks.com/werkspace/topic/15851-documentation-xml-raw-data/#entry105733 Btw. I copied the PHP code you posted above and tried it locally and it worked...

The difference is that martyj uses js for loading and parsing the XML-files client-side, while PHP does that server-side. CORS is a security mechanism implemented by browsers to prevent cross-origin-XSS.

For me it works with the lines you posted (though I used a custom created camera). Are you sure, that is actually your camera? Does AddPostEffect return anything for you (on error you should get -1, otherwise an index).

Thanks for actually drawing that thing out. So you're calculating with theta, while I'm calculating directly with the angle fov/2.0. So that's where that difference comes from. I actually checked back with wolfram-alpha and actually both of our terms are equal. When I first checked it, I forgot that wolfram-alpha uses rad and I had to transform the 90 before checking... So... now at least I can sleep in peace

Oh, my apologies then. I've been trying to make sense of the math you used, but I actually don't get how that's supposed to work or what my formula does wrong then. I get that "math.pi/180" term is only for deg->rad, as the standard math.tan-function works with rad, whereas the leadwerks-Math::rad-function works with deg, but for the rest, you have "tan(90-fov/2)", where I have "1/tan(fov/2)", and these terms are surely not identical... No matter how I draw things out, I always end up with the term I wrote above.

For a minimap I would actually use an orthographic projection mode. I guess, in an orthographic projection, you can simply set the width and the height of the camera to exactly your map's dimensions. If you want to use a perspective projection: macklebee's formula surely looks nice but the map doesn't include the whole map (which I suppose, you want to have). Doing the math I arrive at Q = X/(2*Math::tan(camera->GetFOV()/2.0f)) (though I didn't test it)

In fact, using the ALT-key actually pauses your game. As a workaround: When you switch the window-style, this does not happen. By default the function Window::Create() uses "Leadwerks::Window::Titlebar" as the style-argument. If you simply choose "0" instead here, ALT does not freeze the application. However, ALT is still not recognized using the leadwerks-internal functions. Again, as a workaround, you can use "GetKeyState(VK_LMENU) < 0" from the windows-API: https://msdn.microsoft.com/en-us/library/windows/desktop/ms646301(v=vs.85).aspx As for fixing this problem, this might be helpful: https://www.gamedev.net/topic/612799-keys-alt-f10-freeze-my-window/

I think, you should consider adding this to the API, as Herobot's use-case is quite a good example for the usefulnes of that function. I really hate it, when I alt-tab out of a game to change some setting and I can't because my mouse keeps jumping to the center of the screen. Also, there is relly not more to it than just comparing the output of "GetActiveWindow()" from the windows-API to "window->hwnd".

Yeah, as I said, the function is not documented and thus probably not exported to LUA. This means, you actually have no way to choose the rendered camera and should therefore use a pivot to mark the position of the second camera instead, like I did in my first post. In your UpdateWorld()-function, you then have to swap the position and the buffers and render. Try it like this: Script.buffer=0 Script.mapcam=0 function Script:Start() .... self.camera=Camera:Create() self.camera:SetRotation(0,0,0) self.camera:SetPosition(self.entity:GetPosition(true)+Vec3(0,1.8,0)) self.buffer = Buffer:Create(100, 100, 1, 1, 0) self.mapcam = Pivot:Create() end function Script:UpdateWorld() .... local buff=Buffer:GetCurrent() local mat = self.camera:GetMatrix() self.camera:SetRenderTarget(self.buffer:GetColorTexture()) self.camera:SetMatrix(self.mapcam:GetMatrix()) world:Render() self.camera:SetRenderTarget(buf:GetColorTexture()) self.camera:SetMatrix(mat) end function Script:PostRender(context) .... context:DrawImage(self.buffer:GetColorTexture(),0,0,100,100) end

You can also find an implementation that works without the pivots here (that's only the facing-directions-test without the distance-test, but the latter one is straight forward): http://www.leadwerks.com/werkspace/topic/15187-swordfight-prob-c/#entry102424

Well, actually I just found, that you can call camera->Render() instead of world->Render() (though this isn't documented and thus probably not available in LUA) and you can set a Render-Target. This means, you can actually simplify that a bit: Buffer* map_buf; Camera* map_cam; bool App::Start() { ... map_buf = Buffer::Create(100, 100, 1, 1, 0); map_cam = Camera::Create(); map_cam->SetRenderTarget(map_buf->GetColorTexture()); } bool App::Loop() { ... // Clear both buffers context->Clear(); map_buf->Clear(); // Render both cameras camera->Render(); map_cam->Render(); // Draw the map over the context int blendMode = context->GetBlendMode(); context->SetBlendMode(Blend::Solid); context->DrawImage(map_buf->GetColorTexture(), 0, 0, 100, 100); context->SetBlendMode(blendMode); context->Sync(false); return true; } This kind of cleans the rendering-function a bit.

Even with two cameras you would need to go through all this buffer-swapping-stuff and render the scenery twice. The reason for this is that you can only render the world to the currently enabled buffers. Also I don't know, how/whether it is even possible to switch the currently rendered camera. In order to decrease the costs of this you could do something like changing to a less costly render-mode for the map and decreasing the update-frequency, by only performing the rendering to the map-buffer, if at least X milliseconds have passed since the last rendering.

You will need to use multiple buffers and render the scene twice. You can use a pivot (I named it "map_viewport") to mark the position and rotation of the camera for the map. See the following C++-Example to see, how to do that. If you're using LUA, it should be pretty straight-forward to translate this. Buffer* map_buf; Pivot* map_viewport; bool App::Start() { ... map_buf = Buffer::Create(100, 100, 1, 1, 0); map_viewport = Pivot::Create(); } bool App::Loop() { ... // Clear both buffers context->Clear(); map_buf->Clear(); // Save the current position and rotation Mat4 cur_mat = camera->GetMatrix(true); // Set the camera's position and rotation to the pivot's camera->SetMatrix(map_viewport->GetMatrix(true), true); // Render the world to the map-Buffer context->Disable(); map_buf->Enable(); world->Render(); // Restore the position and rotation camera->SetMatrix(cur_mat, true); // Render the world to the context-Buffer context->Enable(); map_buf->Disable(); world->Render(); // Draw the map over the context int blendMode = context->GetBlendMode(); context->SetBlendMode(Blend::Solid); context->DrawImage(map_buf->GetColorTexture(), 0, 0, 100, 100); context->SetBlendMode(blendMode); context->Sync(false); return true; } Edit: Changed the code to use the transformation-Matrices instead of setting position and rotation, as this should be more efficient Edit2: Changed the blend-mode to Blend::Solid instead of Blend::Alpha

Are you using any other posteffects? If so, the order in which they are executed is important. It looks like in the first picture your image is darkened after applying the rain and in the second the darkening happens before applying the rain.

Look at the description on the second page of the same thread: http://www.leadwerks.com/werkspace/topic/12160-rain-possible/page__st__20#entry88294

Take a look at this thread: http://www.leadwerks.com/werkspace/topic/12160-rain-possible/#entry88234

The main problem is that between frames, if you move the mouse fast enough, you might click somewhere out of the window. The only possible solution for this is to tell the operating system to do so, using the windows-API as I showed in the above code-snippet. So the only way to do so without C++-version is, if Josh adds a wrapper for my 2nd snippet above to the Leadwerks-library, and exposes it to LUA. So Josh, please...? Edit: As a side-note: This does not only concern multi-monitor environments. If you have a non-fullscreen-window, this can happen to you on a single-monitor, as well, so I think many people might profit from a simple "trapMouseInContext"-function that does exactly what I've demonstrated.

If you have the C++-version, you can use the windows-ClipCursor-function for this: I recommend using the following in your App::Loop-function: if(window->Active()) ClipCursor(&window->rect); Using the window->Active-condition will ensure that you only do this, if your window is actually focused (so when you alt-tab, your cursor won't be locked). Also note, that upon moving the window or switching to a different window, the locking will be void, which is why you should put this in the App::Loop instead of at the start of the game (it would be even better to register a callback for focusing and putting it there but I don't think, that will gain you that much performance to actually be worth the troubles). I also noticed that window->rect is a bit off for me (strangely even the GetWindowRect-function returns this "false" rectangle). Also this includes the title-bar and the border. If you only want the area without the border (the so-called client-area), you can use the following chunk of code: RECT r; GetClientRect(window->hwnd, &r); MapWindowPoints(window->hwnd, HWND_DESKTOP, (LPPOINT)&r, sizeof(RECT)/sizeof(POINT)); if(window->Active()) ClipCursor(&r);