The search index is currently processing. Leaderboard results may not be complete.

Member

3

12905

Member

3

392

Moderator

2

14379

Member

2

1093

## Popular Content

Showing content with the highest reputation on 10/01/19 in all areas

1. 2 points

2. 1 point

## Check out this VR game I am working on as Sound Designer, and try it for free !!!

Hi ! I would like to share this VIRTUAL REALITY game I am working on right now ! PriVRateer is a breathtaking space ship battle game that you can play alone or with friends ! A beta testing version is available for free (see bellow): Here is where you can download and play the game: https://discordapp.com/invite/Wt8MkJ7 Don't forget to check out my website and subscribe to my newsletter to get some really cool free sounds all along the year: www.ogsoundfx.com And also check out my Patreon page and see all the goodies you could get all the while helping me out: https://www.patreon.com/ogsoundfx
3. 1 point

## Recalculate normals of a regular grid surface (C++/OpenGL)

See @Krypt0n's answer 🙂 Which is the normal (haha) way to to calculate normals from a heightmap. It does not solve the fact when something is edited/changed, that part must be renewed. But renewing e texture tile is probably more handy than part of a vertex buffer. Yes. That part i didn't get. 🙂 Thanks Write the z values to a single channel texture (check if your graphics card supports such a huge texture) and sample the texture with texture() or textirelod(). But when values change the respective part of the texture must be renewed, so it would be an idea to portion the texture in tiles of a certain size. Not everything is displayed anyway at the same time. But any change to the texture will have effect immediately. It'll look like this in the vertex shader (you probably don't need the position-to-texture ratio if that is 1:1 and the multiplier). Attention at the edges. The texture should have an overhang of 1. // Intake is displaced position vec3 computeNormalCentralDifference( vec3 pos ) { float leftHeight = texture( og_heightMap, vec2( pos.x - 1.0, pos.z ) * u_positionToTextureCoordinate).r * u_heightExaggeration; vec3 left = vec3( pos.x - 1.0, leftHeight, pos.z ); float rightHeight = texture( og_heightMap, vec2( pos.x + 1.0, pos.z ) * u_positionToTextureCoordinate ).r * u_heightExaggeration; vec3 right = vec3( pos.x + 1.0, rightHeight, pos.z ); float bottomHeight = texture( og_heightMap, vec2( pos.x, pos.z - 1.0 ) * u_positionToTextureCoordinate ).r * u_heightExaggeration; vec3 bottom = vec3( pos.x, bottomHeight, pos.z - 1.0 ); float topHeight = texture( og_heightMap, vec2( pos.x, pos.z + 1.0 ) * u_positionToTextureCoordinate ).r * u_heightExaggeration; vec3 top = vec3( pos.x, topHeight, pos.z + 1.0 ); return cross( right - left, top - bottom ); }
4. 1 point

## Suggestions to speed up my custom pathfinding algorithm (clearance-based A*)?

Maybe this is outside of what you want to do or can do, but have you thought of writing the pathfinding bit in C or C++ to increase the speed? If you're interpreting Python, it should definitely be a speed up, but if you're compiling python, maybe there won't be as much an improvement, but it was just a thought. I know, in general C++ is much faster than python https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gpp-python3.html
5. 1 point

## Whack the Mouse

Gaming is more than whacking human hybrids. Since this is in the programming forum - how about you start to learn programming ?
6. 1 point

## Suggestions to speed up my custom pathfinding algorithm (clearance-based A*)?

I think at least some of this has been addressed (or at least discussed) in the thread. Regarding formations fitting through gaps, the formations can fit through even one-cell-wide gaps (see the video for an example) - it's just that that's intended to be a last resort. As for precomputing information for different formation shapes, I think the complexity there is that (as mentioned above) formations aren't limited by their shape, so you can't necessarily use (e.g.) a naive clearance algorithm. The complexity is that formations can traverse any path, but should prefer paths for which the formation isn't significantly compromised. That seems to be the particular complexity that Rammschnev is trying to address. Also, I did suggest preprocessing earlier, but in this case that's complicated by the fact that the map may have dynamic obstacles.
7. 1 point

## editor.jpg

From the album: Ultimate EmmA

8. 1 point

## Suggestions to speed up my custom pathfinding algorithm (clearance-based A*)?

Couple of ideas: If you modify your test example to force classic A* to find the indicated correct route (by closing off all passages that are smaller than required), and run simple A* on it, is it faster? By how much? If it is, the problem should be your extra "obstacle finding" addition to A*. If it's not, the problem is your implementation. If "classic" A* is much faster (e.g. order of magnitude or more): you could try running multiple A* searches with clearance, with gradually decreasing the required clearance (thus avoiding the problem of not finding any solution), or running simple A* on multiple versions of the map (which you could get by processing your map with e.g. morphological erosion or something similar that gradually narrows "paths"). You could do the multiple maps in preprocessing, although you mentioned dynamic obstacles, which would mean you would need a clever way of updating multiple versions of the map. If you go the route of multiple searches, you can even do them in parallel. you could generate a distance field on you map to have the path "gap" sizes available without searching locally at every node. If "classic" A* is not much faster, then you have to optimize your code. Try measuring with a profiler. I'm not experienced enough in python to spot a performance problem just by looking at your code, but the usual suspect in algorithms like this is using containers suboptimally - wrong type of container, copying containers when it's not necessary, etc. You can also consider rewriting the pathfinding in C/C++ and calling it from your Python code.
9. 1 point

## My main complaint with OOP

The religion Simplicity is not an art to be frowned upon, for it takes courage to stand with the inexperienced and see the world with their fresh untainted eyes. Bless thee who admits having the sin of personal bias and learns common sense, for thou shall ascend into a multi-paradigm programmer. The bizarre We used to have a rule at the company against global functions. Ended up with expressions like "(x.cos()+1).sin()" instead of "sin(cos(x)+1)" because the language's core math library wasn't OOP enough. The developers making advanced algorithms could barely work anymore and it was later replaced with normal math functions again. The milking cow Workers who feel that their skills are no longer needed at the company will always find new ways to pretend that they're doing something useful. Mostly to protect the fragile ego, otherwise they would idly browse Facebook in plain sight like the others. OOP was something that allowed solving complex problems that didn't exist to begin with. One can spend years maintaining bloated frameworks or go around changing the style back and forward while causing version conflicts, adding administrative overhead and introducing defects without having to solve any real problems for the customers.
10. -5 points

## Whack the Mouse

Why would you answer "no"? That's the most trolling answer. This is my favorite song: I'm gonna listen to this violent song until people answer "yes". P.S. This song is exactly as violence as Call of Duty, Mr. Pickles, and Shrink Ray Island P.S. If you can't do it on flash, then you can do it on Unity and put it on Itch.io Let me get something straight. This is the cat and this is the mouse:

1. 1
Rutin
10
2. 2
MJP
7
3. 3
4. 4
5. 5
• ### Member Statistics

• Total Members
260570
• Most Online
6110