Jump to content

  • Log In with Google      Sign In   
  • Create Account

Erik Rufelt

Member Since 17 Apr 2002
Offline Last Active Today, 01:54 PM

#5247686 Heightfield

Posted by Erik Rufelt on 19 August 2015 - 09:39 AM

You sample the 3 vertices from the heightfield that forms a triangle around your position, and then calculate the height of the triangle at that position.



Not sure why you would do that manually when you have PhysX though.. as there's a method to get the height anywhere in the height-field, the getHeight(x, y) method.

Docs here: http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/apireference/files/classPxHeightField.html


I'm sure Unity has similar methods exposed to scripts, a quick Google shows TerrainData.GetHeight(x, y).


If you need to do it manually, you have to do the same triangle-grid as PhysX does. Each triangle forms a plane, the height of which you should be able to easily calculate when you have a position (calculate intersection of the plane along the vertical line at that position).

#5247635 Heightfield

Posted by Erik Rufelt on 19 August 2015 - 05:58 AM

Also the question doesn't make sense (just like the older post linked by Lactose). You need to explain what you're asking about.

PhysX defines exactly how it does intersection testing to heightfield triangles in its documentation.

#5246879 Vulkan is Next-Gen OpenGL

Posted by Erik Rufelt on 16 August 2015 - 06:01 AM

Is extreme shortsightedness a requirement for joining Khronos?


I would say it's the other way around, if they were shortsighted they would just have released long ago. They're holding off to get 10 different vendors to agree on compliance that fits 20 different software teams, in order to not have to redo everything again. The complexity of getting that to work is huge in itself, and fitting into each others schedules surely even more difficult.

It's hard to say if they'll pull it off, but looks like they have some very intelligent people working on it so doesn't seem impossible.

#5246595 What am I doing wrong with these vertex attributes

Posted by Erik Rufelt on 14 August 2015 - 05:40 PM

Try glVertexArrayAttribIFormat with the "I". Might be more functions that are different for integers... not sure right now.


EDIT: The reason is that it static casts to float otherwise (so float-bits will be interpreted as integer-bits in the shader), or if normalized is set to true instead converts it from its full integer range to [0, 1] or [-1, 1].

#5246583 What am I doing wrong with these vertex attributes

Posted by Erik Rufelt on 14 August 2015 - 04:36 PM

glVertexArrayAttribFormat has 0 for the index everywhere.. so guess the last one with an integer overrides the first.

#5246262 PeekMessage changed in Windows 10?

Posted by Erik Rufelt on 13 August 2015 - 11:47 AM

I think you misunderstood samoth's post.. at least unless I completely missed the point. He says it's easy to get an impression from MSDN that couldn't possibly be true..

#5246240 PeekMessage changed in Windows 10?

Posted by Erik Rufelt on 13 August 2015 - 09:57 AM

From SendMessage docs: https://msdn.microsoft.com/en-us/library/windows/desktop/ms644950%28v=vs.85%29.aspx


If the specified window was created by the calling thread, the window procedure is called immediately as a subroutine. If the specified window was created by a different thread, the system switches to that thread and calls the appropriate window procedure. Messages sent between threads are processed only when the receiving thread executes message retrieval code. The sending thread is blocked until the receiving thread processes the message. However, the sending thread will process incoming nonqueued messages while waiting for its message to be processed. To prevent this, use SendMessageTimeout with SMTO_BLOCK set. For more information on nonqueued messages, see Nonqueued Messages.


Some messages are sent to WndProc from CreateWindow, some maybe from ShowWindow (I think..).


The messages that can block badly are probably posted to the thread, whereas the ones sent on starting the app for example are probably sent by a separate thread that handles the starting of that particular program (cursor turns to hour-glass and the app has 10 seconds I think to set up properly and become response, and otherwise you get "unresponsive" notifications if there's a window and waiting is stopped).


SendMessage can return errors (which could happen if a thread crashes while waiting for example).


There is (or used to be?) some option in Windows to let explorer open windows in different threads or processes or something that could change responsiveness..

#5245703 Vulkan is Next-Gen OpenGL

Posted by Erik Rufelt on 11 August 2015 - 05:23 AM


Well.. isn't Valve writing the drivers for Intel, or am I confusing this with something else?

Seems from the comments by people working on major engines that it probably already runs desktop, just not well enough to make it a good idea to release just yet.


EDIT: And by "well enough" I mean compliance for different systems and vendors. Microsoft can just set their things the way they want, but if you want to avoid 5 different behaviors before the final spec is even released while supporting open source systems and very different platforms I think they're pretty smart in making sure all key players are on the same page before finalizing anything.

#5244923 Heightfield Interpolation

Posted by Erik Rufelt on 07 August 2015 - 05:08 AM

I would assume either bilinear, or actually using the triangles for collisions. The latter is a good idea if you want visuals to match exactly (as in objects never floating slightly above or slightly below the visible terrain, which you can get if you do collisions separately from the visible geometry).

#5244848 The Feature Level 9_3 and Virtual Box question

Posted by Erik Rufelt on 06 August 2015 - 10:09 AM

It at least somewhat supports DX11, I've used it for Windows Store apps (on feature level 9.3 I think, but don't remember right now). I had some problems with flickering though and sometimes the screen turned black, so no perfect support probably but enough to test that an app runs usually. https://www.virtualbox.org/manual/ch04.html#guestadd-3d

#5244797 glLinkProgram crash on Intel

Posted by Erik Rufelt on 06 August 2015 - 05:17 AM

It's not unlikely that it's a driver bug. I've encountered a similar issue on Intel DX11 driver where a geometry-shader crashed the display-driver even, and once a particular beta version NVidia driver that gave incorrect results, so it happens.


If you want to be sure, save the pre-processed shader without any #ifdefs, and create a minimal app that draws one triangle with it.


I reported the issue I had with the geometry-shader to some Intel forum and they asked for crash-logs. (In the case I encountered they never fixed it though, at least for the particular platform I used, as no new driver update ever appeared, but if it's a new one that they still update they might :))

#5244045 Trilinear texture filtering

Posted by Erik Rufelt on 01 August 2015 - 02:32 PM

Because of texturecoord-swizzling (Morton order) it will hopefully be 2 cache-lines, one per mip-level, not counting anisotropic filtering, + fetching will probably be done in parallel. Cache etc. is certainly optimized to match common usage as well.

For GPUs latency is also very well hidden by multiple pixels being shaded at once (like hyperthreading). Just as a simplified example, say the shader is run 25 times per core, and there are 4 cycles of calculations setting up texture-coords and start a texture-read, followed by 100 cycles latency waiting for the texture data. That would allow the first instance to do its 4 cycles and start a texture-fetch, at which point the scheduler would interrupt that instance and tell a second instance to run and do its 4 cycles followed by its fetch, etc.. until all the 25 instances are done with their first 4 cycles and 100 cycles have passed.

At that point the results from the texture-fetches have started coming in, and the first instance is allowed to resume, now with its texture data readily available in a register, and each instance is run in sequence again doing what they need to do once the texture color is available. So the entire 100 cycle latency is hidden in this case.

Most of the 25 instances will also probably fetch texture-data from shared cache-lines so not all 25 fetches have to result in actual texture reads (which may matter more or less in real scenarios).

There are often a very large amount of registers in total per core, and each of the 25 instances may have for example 10 registers each (if there are 250 per core), which makes switching between them possible without wasting any cycles.

If each shader-instance would only require 5 registers for example when 250 are available, 50 instances could be run instead on one core, which would allow 200 cycles of latency to be completely hidden instead of just 100, for the same 4 cycles of calculations per texture-fetch. Exactly how this works probably differs by GPU.


EDIT: Edited for clarity (I hope :) )

#5244034 Can't run GL_NV_path_rendering extension demos

Posted by Erik Rufelt on 01 August 2015 - 12:55 PM

Strange. Perhaps the demos are run on Intel graphics by default, if you have auto-switching graphics on your laptop. Try setting the default to the NVidia.


Or print all available extensions to see if everything looks right.

#include <fstream>
#include <string>
#include <algorithm>
#include <gl/gl.h>


wglMakeCurrent(hDC, hGLRC);
	std::ofstream file("extensions.txt", std::ios::trunc);
	file << glGetString(GL_VENDOR) << '\n' << glGetString(GL_VERSION) << "\n\n";
	std::string str(reinterpret_cast<const char*>(glGetString(GL_EXTENSIONS)));
	std::replace(str.begin(), str.end(), ' ', '\n');
	file << str;

And if it's still missing make sure you have the latest drivers (nvidia.com).

#5242409 Slow BSP-Tree visibility checking

Posted by Erik Rufelt on 24 July 2015 - 08:55 AM

How many objects in total?


Some micro-optimizations:

Is the distance-test squared or do you do the sqrt? (should be irrelevant but one of those things..)

Is that test done once and applied to all 5 lists, or do you use a separate distance?

Can the lists be combined to one?

Remove the iterator-loop and change to something like first obtaining vobs.data() and iterating with an index. (Probably shouldn't but often does make a difference).

Try changing alreadyCollectedFromTree to something like integerSet.contains(vob ID).. you could start with std::set<int>, though I think that does allocations so you might want to find another one or use an allocator.. unless you already do it like that. Also remove the function-call and make that ID public constant or something.

Does DrawVob have to be virtual, or could it be optimized to like a list of indices or IDs that could be pre-computed on create and/or update-methods unrelated to drawing?

Do 'collectedFromTree' and 'bspDrawnVobs' have to be two lists, or do they share the same information so they could just be the same integer-set?


Maybe show the whole method and not just the part inside the distance-check too..

#5241717 How to "glue" mouse to a window (multimonitor)

Posted by Erik Rufelt on 21 July 2015 - 08:54 AM

SDL_SetWindowGrab it seems.