SpiderPig
-
Posts
2,411 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Downloads
Posts posted by SpiderPig
-
-
Yes it is fixed now
-
Version 11 runs good for me. Still have this icon issue though.
-
1
-
-
2 minutes ago, Josh said:
I don't see how you can resize those members because the public members are read-only.
I may have "un-const" them
Not a good idea I know, but I'm waiting for the public Set() commands. Sorry
5 minutes ago, Josh said:Data transfer at that level should be no problem at all. I don't know the exact size of the vertex structure, but it's probably somewhere around 72 bytes, so 1000 vertices is only 70 Kb fof data.
I did a quick check - sizeof(Vertex) = 116 bytes. If I double up on vertices between voxels and every voxel had a vertex on every edge, so 12 vertices each, 128x128 voxels would be : 128x128x12x116 = 22,806,528 bytes. 22MB. Even though it's only once every so often that seems like a bit of an ask... but I'm not sure
-
1
-
-
Thanks I'll see what I can improve!
1 hour ago, Josh said:For high performance C++ you can basically assume that math operations are free but memory and stack allocations are costly.
I think memory allocation is my biggest enemy at the moment so maybe I should fix that first and then see how fast it is. I'm also becoming aware that recursive functions are really useful but appear to get really slow if your using a lot of them, probably from lots of heap allocations - or stack allocations I can never remember which is which. I think if I could get rid of recursive functions it'd probably be 10x faster.
1 hour ago, Josh said:Mesh size in Ultra is fixed. Once the mesh is submitted to the rendering thread you can't add vertices or primitives. This allows the renderer to offload additional overhead onto the culling thread.
Currently I am resizing the vertex and indice array of a mesh so maybe this is creating a bottle neck. Is the re-submission of mesh data very costly? Dependent on mesh size of course but is 1,000 vertices seen as a piece of cake or not a good idea?
-
Another option could be to use a single vertex per node and use the Geometry shader to build the voxel itself...
-
Been working on voxel terrain and have reached a crossroad. Currently everything is done on the CPU. The terrain is about 1024x1024x1024 and made of a grid of components (with each one being a model) that are 128x128x128. Only the components that are currently intersecting the surface level are actually made. When the LOD of a component changes the mesh of that model is edited by indexing the vertex and indices arrays (to maximise speed). This is fine for lower LOD levels where each node may be 4m or larger, but getting down to 1m size nodes it can take up to 1 second for the whole thing to update. I always knew the GPU would have to be utilized somehow which leads me to my question, is the compute shader the way to go here?
I'm thinking of having a 3D texture for each component that simply holds the triangulation index of each node. I can store that index (0 - 255) in one byte so I think a 128x128x128 texture would only be about 2MB, and a lot smaller if the node size is larger than 1m. I may end up sending some more information in the texture later on so if it's fast enough it may end up being a 3 or 4 channel texture. I have no idea if an 8MB texture can even be sent quickly to the GPU... it won't be every frame. Just for the component that needs updating when the LOD changes. At most there may be 4 or 5 components that require an update at once and this could even be staggered over several frames.
I'm just not sure if the compute, vertex or geometry shaders are best suited to take a 3D texture and spit out some tringles. None of the information needs to come back to the CPU, its just to create the visuals. I can use the same indexing on the CPU to generate collisions meshes.
I believe I can speed up the octree subdivisions by creating large blocks of contiguous memory for the octree nodes rather than creating and deleting each node as they are needed.
I'm using a signed distance field on the CPU side to generate the basic terrain shape. Got it working pretty fast so for now I think I will leave the generation side of things as it is.
A quick smoothing makes it look more like a floating island...
I still have to finish the voxel triangulation table - there's still a few holes in the mesh.
-
Is CurveValue() now CurveAngle()?
-
Just updated a project a few times and my project directories are looking like this.
Also after each restart of the client it will still say that these files need updating for each project I have.
Going to test out the player controller soon!
-
-
I think that's what's happening here too. There are four red spheres and two white (or grey) spheres. The sides that are facing the directional light are solid white.
-
It's looking pretty good. Once the loading of materials are working again I will test this out with some of my own models.
Small query for you - I'm sick of VS2022, it's always crashing and restarting even on small projects, and intellisense stops working correctly after a few hours. I want to use VS2019 again but can only compile with the v142 toolset instead of the 143 in 2022. I get one error in doing so;
1>UltraEngine_d.lib(Skeleton.obj) : error LNK2019: unresolved external symbol __std_find_trivial_4 referenced in function "int * __cdecl __std_find_trivial<int,int>(int *,int *,int)" (??$__std_find_trivial@HH@@YAPEAHPEAH0H@Z)
I take it this can't be done if you've compiled Ultra with v143?
-
What if you casted a ray from a few of the players AABB corners to the light and used a weighted average of each result? I'm not sure how fast each ray cast is though. You could do a quick ray cast to see if there are any AABB's along the way to the light, then do the more complex check after that. Maybe there's also a way to use the shadow map - if you can access it... I don't know exactly how the shadows work but if you could see how much of your player was visible in the shadow map that might do the trick.
-
1
-
-
Heaps faster, looks great!
-
I don't know for sure - but the loop seems faster to me than heaps of scripts. LUA is slower than C++ so I would think the less Leadwerks has to go back and forth between calliing a script the better. Somone else may have a more definate answer.
-
1
-
-
Good luck! 😁
-
1
-
-
A few of us are testers. Its not finished yet.
-
Sprites that show text are completely white now too... shader issue?
-
Just in case it matters both updates are working for me.
-
Looks incredible!
-
On 9/20/2022 at 9:05 PM, Alienhead said:
I plan on moving to Ultra but it'll be after I finish this current game. I'm in to deep to worry about any porting at this point. I started this project back in March, so about 7 months now. It's went through some major face lifts and design changes since the original base game I had laid out ( original ).. I really have 2 main projects I switch back and forth between to prevent staleness but this one is my love and the project I plan to see to completion. I'll probably carry my zombie tower defense game over to Ultra when the time comes ( zombie TD ). Thanks to Leadwerks modular design It's pretty easy to carry over scripted logic between projects.
When Ultra was in it's early days I ported my 8 month project over, it broke everything and although I've still got all the working library's there, it's going to take a lot of work to put it all back together again. If Leadwerks handled the scope of my game I wouldn't have bothered about moving it over. But Ultra's speed lured me in. My advice is if Leadwerks handles your game fine leave it at that and start any new project in Ultra.
I have about 10 projects I bounce between but I think I've settled on one now
-
3
-
-
Sprite::SetRenderLayers()
Got it drawing but it draws like this;
-
Do I need to assign the sprite to the ortho camera? I have one setup and creating a sprite result in this;
auto sprite = CreateSprite(world, font, "test", font_size);
EDIT : Or is this a "2D game only" thing?
-
1 minute ago, klepto2 said:
I get around 150 fps but this is because the rendering of the diffuse irradiance is very heavy and needs to be optimized or another faster way needs to be found. Through the nature of the precomputation, the sky and reflections are rendered in ~1ms (maybe faster).
150 is pretty good.
2 minutes ago, klepto2 said:Now i am starting withthe cloudsystem
Volumetric?
@Josh What's your plans for sprites now? I see they are created in 3D space rather than 2D as before...
-
Looks great, good job. What's the FPS like?
Not a good idea I know, but I'm waiting for the public Set() commands. Sorry 
VoxelTerrain Speed
in Programming
Posted
I've found half the problem - I was clearing the indice array and then still using AddPrimitive() to create each face. In debug clearing the largest patch was taking 50ms and rebuilding it was taking 90ms.
component->mesh->indices.clear(); ... component->mesh->AddPrimitive(current_vert_index, current_vert_index + 1, current_vert_index + 2);I won't be able to fix this until there's a way to to properly set the vertices and indices of a mesh all at once.
I'm wondering if it would be faster to create an entire new mesh instance rather than editing an existing one. It seems though we can only add a mesh to a model rather than swapping it out completely? Is this for the same reason below?
Resizing the arrays to be smaller or larger has actually worked - so should it not be done for performance or is it slowly breaking the renderer?