Josh
-
Posts
23,402 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Blog Comments posted by Josh
-
-
Honestly, right now I am approaching my breaking point. Explaining the last three years of work in a rigorous academic format was hard. The whole process from conception of the idea, to experimenting with it, finding out it actually works, implementing the full solution, and then creating the final benchmarks, which turned out VERY VERY good...it has been a huge journey and I think I am presently the only person in the world who is aware of just how big this is. I applied for some grant money from the U.S. government, and that could make a big difference, so fingers crossed. My plans for the rest of the day are to maybe drink some tea. That's all I can answer right now.
-
1
-
-
On 4/19/2018 at 9:12 PM, Crazycarpet said:
The reason you'd want to multithread the command process is for situations where big, new, powerful GPUs are bored because the CPU's one thread can't send it commands fast enough to utilize it to the fullest extent. That's not a fair analogy
so long as your GPU can handle it, why would you not want to throw more work at it? Modern GPUs (10 series, etc) can certainly handle it.
A great GPU can handle anything a single core on your CPU can throw at it with ease, so you want to throw more at it. This is the most common bottleneck in games these days with how powerful GPUs are getting. The better your GPU, the better these optimizations will help, it's more planning for the future because as time goes on you'll see more and more improvements from this type of multi-threading, that's why DX12 and Vulkan moved towards it.
Anyways like I said, it isn't usually necessary but it would be optimum, just food for thought so you consider this design if you move towards a Vulkan renderer. It'd be a shame to use Vulkan and just move all the rendering to a thread, instead of using all available threads for command buffer generation.
Your general sentiment is correct, but the fact is, the idea of "commands" is kind of antiquated. It's more like "hi, I am the rendering thread, here is a block of bytes you will interpret a few times before the next block of bytes arrives, k thx bye".
-
I've got it working so if you load the material file "https://raw.githubusercontent.com/Leadwerks/Documentation/master/Assets/brickwall01.mtl" it automatically loads the texture file from the same directory. Inside the material file, it just says the texture is "./brickwall01.dds", and the engine figures out the relative path and downloads it.
-
1
-
-
Here are my last screenshots of the CPU-based GI algo:
-
1
-
-
I solved one major problem with light bleeding through surfaces and I am going to move the GI calculations over to the GPU now.
-
1
-
-
LE5 beta now updated with added debug info:
-
This library might be useful for simple IK:
https://github.com/TheComet/ik -
Another update is available, adding this and dynamic navmeshes.
-
1
-
1
-
-
It actually accepts separate values for all three axes. I am using zero for X and Z and 0.35 for the height, which seems to work, but I will add a radius parameter for XZ and an optional height parameter.
-
3 hours ago, gamecreator said:
Wow. This is a huge improvement over the current system. Make it dynamic and it'll be perfect. ?
I'm not clear on how finding points on the navmesh works. How do you do a pick on the navmesh? Or does IntersectsPoint check a radius around the point and return the nearest one? If so, how do you change that radius?
In this example I am doing a regular camera pick and then checking to see if that point lies on the navmesh. I do not have the radius value exposed because I didn't see a point to that, but if you want I will add that in as an optional parameter.
-
The physics system is an IK system, and could be used for character joints. It's not easy, but renaming a bunch of commands would not make it any easier.
-
No plans for this.
-
34 minutes ago, Lethal Raptor Games said:
Looks great! What if we wanted to animate an object manually? Like use code to make a player walk over certain obstacles, is this possible?
Bones can also be positioned with code, using many of the same commands as the entity system (although they are not the same code internally).
-
1
-
-
Just now, gamecreator said:
Do you know yet if you'll improve on the navmesh (i.e.: make it dynamic) and the water (multiple non-infinite planes, return of oceans, rivers)?
Navmeshes will be dynamic, and will need to be created in a certain area instead just being everywhere across the world. You can have multiple navmeshes.
I am planning for water to use the same reflection system that is in use for all surfaces, so there is nothing special about its appearance. The physics would be easy to contain in a volume, so you could have lots of different blocks of water here and there.
-
2
-
-
-
Nice article.
-
This actually solves big problem I had with the voxel GI system, which was memory / bandwidth. I was going to implement a complicated octree structure encoded in texture data but if I use DXT1 compression with 1-bit alpha the voxel data will shrink to 12.5% its original size.
-
I changed it so with compressed images you are inputting pixel values, but the values must be evenly divisible by four. The routine will even automatically clip the edges of the regions so you don't get an error when going outside the bounds of either image.
-
Adding the LOAD_NO_OVERRIDE load flag in any load command will prevent this system from changing the file extension.
-
The pink normal maps were bothering me so I made it so when the engine encounters a DXT5n image (these will only come from LE4 .tex files) it converts it to RGBA and swizzles the red/alpha channel. So you can say goodbye to pink normal maps forever, and I can remove the swizzle functionality in the Vulkan texture class. You should use BC5 for compressed normal maps.
-
Decompression is fast, but I have not gathered any numbers. A fair test would be a zip compressed DDS vs. an unzipped Basis file. (Even if you store a Basis file in a zip package there is no point to adding zip compression because it won't make it any smaller.)
-
1
-
-
Update is available now!
-
I was curious to see what would happen if I ran the compressable images through Crunch. The final result was 27 MB, which is 55% the size I got already and 25% the original uncompressed data size (with several minutes of processing time). This isn't a huge difference over the existing compression, but it's enough to consider working that into the pipeline in the future. For general texture data, it could definitely make your game install size quite a bit smaller, if you were using DXT but BC7 is so much better I don't see why you would want to.
-
I am planning to store all code samples on Github here:
https://github.com/Leadwerks/CodeSamplesI am not sure if we will do one sample per command, or just have some more general samples that include a lot of different commands for each subject, or maybe both. I don't know if they will be linked to or shown on the documentation page itself.
so long as your GPU can handle it, why would you not want to throw more work at it? Modern GPUs (10 series, etc) can certainly handle it.
Current Work
in Development Blog
A blog by Josh in General
Posted
Oh yeah, there is something else I have to do this weekend. I have to finish a description of the technology I am filing a patent for. I'm working with a law firm with some folks from Oculus, with the idea that they will have a better understanding of this type of tech. Once the provisional patent application goes in, the clock starts ticking and I have one year to file the full utility patent. The patent makes the company valuable, and increases the chances that Valve will buy the company and hire me to make their future dev tools.