• Content count

  • Joined

  • Last visited

Community Reputation

2224 Excellent

1 Follower

About Kaptein

  • Rank
    Advanced Member

Personal Information

  • Interests
  1. Object placement in O(1)

    This is for try-placing objects, so no searching is necessary. For each position (x, z) in the world, read a seamless pre-computed array of radius-values and compare lequal against radius of object you're trying to place. This was 5 years ago, but I don't remember the details unfortunately. I ended up finishing the poison-disc generator and now my objects are try-placed properly in O(1), and seamlessly wraps around on the arrays. One (singular) array can't be used with many objects of many sizes, though, but I'll live. The bottom line here is that I can't use my poisson-disc array to place both big and small objects interchangeably. Instead I would have to create two arrays to support two object sizes, or one array where the one object affects placements of other objects, which is also unwanted. The primary reason for having something like this is just being able to use the same array to place any kind of size object from a single array shared across all threads.
  2. Object placement in O(1)

    Today I started implementing Poisson Disc generator, however halfway through the implementation I realized this was not what I was using 5 years ago. First off, while I can implement this with a min and max radius, it doesn't help me fill in the void (so to speak) if I should generate a wrappable array from this data. So, this is what I need to know the name of: 1. The algorithm probaby uses poisson-disc to start with 2. It then creates a power-of-2 sized array 3. It fills the array with radius-values, distanced so that if you access the array at any position modulo the array size, you can use lequal to know if you can place your object. An example row: [1, 2, 3, 2, 1, 2, 6, 2, 1, 2, ...] <-- if i remembered the specifics I wouldnt be asking 4. This is O(1) because an object can be try_placed with `array(wrap(x), wrap(y)) < radius` Anyone know the name of this procedure? Any help would be appreciated.
  3. I am currently implementing UBOs and Buffer Textures in an effort to go from using glUniforms which are quite decent performance to something more per-frame and per-world-transition. I have a few thousands of mesh chunks that are generated for coordinate (0, 0) so that I can translate them wherever I need. I'm now doing the translation with a glUniform call each time I make a draw call. I would like to transition away from this by using UBOs (once per frame to setup all per-frame stuff) and then using texture buffers to translate and get better control over chunks. 1. Is this new method much faster than before? If the answer is no, it might not be worth it for me 2. How do I make sure that a given mesh that knows nothing about itself can sample from the right index in the texture buffer? There might be a ray of hope here if each draw call could be numbered from 0 .... N-1. EDIT: I baked in a mesh ID in all meshes and used a vec3 buffer texture as translation to avoid setting any kind of uniform data at all. I didn't notice any performance improvements.
  4. Noise derivatives

    Can anyone explain to me how to use analytical derivatives in noises for use in 3D terrain? I have made a very capable game engine but I'm unable to make any cool terrains due to not being good at math. I have looked around on the net but it seems terrain generation is just a creative art no one teaches. For starters, how about how to perturb the top portion of a density bubble so that we can increase the chance of unbroken terrain with overhangs, as opposed to disconnected terrain due to too much perturbation? http://www.iquilezles.org/www/articles/morenoise/morenoise.htm gives an introduction on the topic and shows that it can be useful (which I wasnt sure of beforehand)
  5. Hey all, this is mostly a thinking problem. I have terrains, all of which are placed on an N-dimensional graph/system which determines their wetness, temperature etc. The conversion from a biome coordinate/point to a terrain is done by simply finding the closest terrain point/coordinate in the system. Think voronoi diagram. Given that there are very few terrains (lets say 20), shouldn't I just be iterating over each point and determine which is closest? What would you prefer? I have implemented uniform voronoi cells myself for creating simple zones, but I feel like using a Voronoi diagram just for this is overcomplicating it.
  6. There should be a stack for each execution environment, so threads, fibers and interrupt handlers get their own. There is also separate stacks when switching to kernel simply for security reasons. Otherwise, I would only switch stack if I needed a really big one for something, and that hasn't happened yet. We just make regular function calls into DLLs, so it's all executing inside the same execution environment. I would assume DLLs also used the standard libraries for memory management, if the code in those DLLs make calls to new/delete or malloc/free then that's what's going to happen.
  7. CMake is insane on Windows

    Yea the build folders are cleaned out each time, so unless there are some hidden files it should be empty
  8. CMake is insane on Windows

    Unfortunately, it's the same output as before: it detects CLang 4.0.1 and then proceeds to MSVC EDIT: I tried cmake with MSYS, and I also get the same output: cmake -G "MSYS Makefiles" -DCMAKE_CXX_COMPILER=/c/LLVM/bin/clang++.exe -DCMAKE_MAKE_PROGRAM=mingw32-make .. ... /C/LLVM/bin/clang++.exe /nologo /DWIN32 /D_WINDOWS /W3 /GR /EHsc /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 Even if I should find some hack to make this work, it shouldn't be behaving like this.
  9. I am trying to build with Clang on Windows for the first time. I usually use G++ but it creates large static files which irritate me. I also want to try CLang on windows, since I use CLang exclusively on Linux. There is nothing that seems to work to make it stop sending "MSVC-like" parameters to the compiler. How can I disable MSVC-detection? It clearly says: C:\Projects\dm2\clang>cmake .. -G "MinGW Makefiles" -DCMAKE_CXX_COMPILER="c:\\LLVM\\bin\\clang++.exe" -- The CXX compiler identification is Clang 4.0.1 -- Check for working CXX compiler: c:\LLVM\bin\clang++.exe -- Check for working CXX compiler: c:\LLVM\bin\clang++.exe -- broken ... c:\LLVM\bin\clang++.exe /nologo /DWIN32 /D_WINDOWS /W3 /GR /EHsc /D_DEBUG ... predictable output ... what's going on here? EDIT: I'm using newest CMake, newest LLVM for win64, newest MSYS and MinGW64. I am successfully building statically with G++ as of writing this.
  10. Profiling

    Yeah. live stack sampling is more of a "we don't have any other choice, because its hardware". It does have some positive traits though, eg. if the sampling source is bias-free then so are the samples. I'll defer to your experiences with full frame analysis. I always thought I would want to see data on a specific point and then "do things" in the game to figure out how that area changes in time-cost. Your answer on the cells seem right to me. Sounds like uniform voronoi grid thing I did ages ago. Thanks.
  11. Profiling

    Hey all, As the code slows to a crawl we have to instrument our binaries, but its been a while since I did programming on a platform that had options. I'm used to live stack sampling inside small kernels, and because of this I don't want to go back to the stone-age of fully instrumented executables. I had a look at CxxProf: https://github.com/monsdar/CxxProf/wiki/What-is-CxxProf%3F and it looks nice. Especially the part where you can pick and choose where it does the work. But, before I go ahead and do all this integration, what profilers do you use? Not to mention, CxxProf hasn't been updated in 3 years, although hopefully it still works well. Actually, I have to sneak in a second question. I'm dividing my levels into a grid of X*X cells so that I only have to iterate over the cells (X-1 to X+1, Y-1 to Y+1) to find nearby objects. Using a "hash" of the cell position to assign objects to cells, where each cell has a set of objects. Does this sound like a plan?
  12. I need some advice. After I changed my scripting language from in-memory C to Lua I've had numerous problems I've never encountered in other languages. Prototypes? Type signatures? Calling functions with any number of parameters? How do you deal with all the random bugs you can get that you have really no way of determining the cause of? If I call a function with one less parameter than it should have, I might just get a Lua error somewhere else in the script. At a later time. What do you do to make your code (which isn't bottlenecked at all, so there is tons of room to add checks and balances) more correct and more sane? If I scripted sanely in C I would rarely have these issues. For example any pointers passed between the engine and the script goes through a sanitizing stage where it actually checks if the pointer points to an actual valid existing entity. If it sounds like I am regretting the change, I don't know how to answer that. Lua can construct tables and pass them around, which is very nice, unlike C where I would have to malloc (and that is just not going to happen).
  13. I actually haven't tried that interface yet. All I wanted to do was pass a memory address to Lua, which Lua should interpret as opaque and just pass back as parameters to my engine interface. I will probably try the class-like method at some point and see how useful it is.
  14. sleep c++

    POSIX has usleep which can sleep for microseconds, although if the sleep is very short its probably just a pause loop. If you are using a non-decade-old compiler you'll also have access to: std::this_thread::sleep_for(std::chrono::microseconds(usec)); in C++, which will be portable.. if that means anything to you
  15. I solved this, for now, by passing uintptr_t around. Thought about putting the objects index into the 16 unused address bits, but I haven't needed it yet. It's very strange though, that LuaBridge can't pass even void* around. I would understand it if it tried to translate objects (I've seen the more complex usage), but void* should just be passed around as an opaque pointer, which is what it was designed as. Disappointing too. And why am I not Prime Members anymore