Josh

The whole system should be instant. I will check this out tomorrow. Sorry for the inconvenience.

Oh boy...I will check it out tomorrow. I need to change your password so I can log into your account in the client. Is that okay? The point rendering also is not available yet. I'll publish the update for that tomorrow. I don't recommend messing around with shaders yourself unless you want to. I think I can make a special shader family just for rendering point clouds, with almost everything stripped out of it.

This is the code I used to load that... #include "UltraEngine.h" #include "ComponentSystem.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { //Get the displays auto displays = GetDisplays(); //Create a window auto window = CreateWindow("Ultra Engine", 0, 0, 1280, 720, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); //Create a world auto world = CreateWorld(); world->SetAmbientLight(0); //Create a framebuffer auto framebuffer = CreateFramebuffer(window); //Create a camera auto camera = CreateCamera(world); camera->SetClearColor(0.125); camera->SetFov(70); world->SetAmbientLight(1); //Camera controls auto actor = CreateActor(camera); actor->AddComponent<CameraControls>(); auto stream = ReadFile(GetPath(PATH_DESKTOP) + "/T1.txt"); auto model = CreateModel(world); auto mesh = model->AddMesh(MESH_POINTS); while (not stream->Eof()) { auto s = stream->ReadLine().Trim(); if (s.empty()) continue; auto sarr = s.Split(""); if (sarr.size() < 6) continue; auto v = mesh->AddVertex(sarr[0].ToFloat(), sarr[2].ToFloat(), sarr[1].ToFloat()); mesh->SetVertexColor(v, sarr[3].ToFloat() / 255.0f, sarr[4].ToFloat() / 255.0f, sarr[5].ToFloat() / 255.0f); } model->UpdateBounds(BOUNDS_ALL); //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { world->Update(); world->Render(framebuffer); } return 0; }

All you are doing is calling Time::Update twice, in a really convoluted manner.

You should not do this.

Here's a first pass at this. Point cloud meshes don't need an indice array, so I need to go in and figure out how to get rid of that when MESH_POINTS is used, as it will be more optimal without that. The vertex structure also includes a lot of data a point cloud does not use, like texture coordinates and normals, so maybe I can create a special optimized vertex buffer just for point cloud rendering. It would make a significant difference in speed, as LIDAR data is one of the rare cases where the vertex pipeline actually is the bottleneck.

I was able to load your text file, but I am getting this Vulkan validation error: So I will need to muck around in Vulkan a bit more before it works. I actually thought point sizes had vanished from the pages of history.

Updated 1.0.2 Pixmap::CopyRect now much faster, especially when a streambuffer pixmap is used Fixed errors in Pixmap::Sample linear filtering Fixed Pixmap::WritePixel bug Fixed it so Pixmap::ReadPixel and WritePixel will now work with very big images Pixmap conversions now all work without calling Buffer::Data, for compatibility with StreamBuffers Added a few missing pixel format conversions Added Pixmap::Blit Added Pixmap::Extract Fixed Entity::AlignToVector bug Fixed joint deletion bug Fixed component collision bug Stream::Read and Write are now broken into 8 Mb chunks

Do you know what the text info means? I am guessing it's vertex position / RGB color / some other info I don't know: -1.38699996 -5.33300018 0.15500000 0 36 218 -2032.000000 9.000000 9.000000 9.000000 9.000000 -1.88900006 -5.35699987 0.19300000 0 44 210 -1991.000000 9.000000 9.000000 9.000000 9.000000 -2.05200005 -5.37300014 0.22499999 0 52 202 -1982.000000 9.000000 9.000000 9.000000 9.000000 -2.07200003 -5.36299992 0.22300000 0 51 203 -1975.000000 9.000000 9.000000 9.000000 9.000000 -2.06599998 -5.36199999 0.22400001 0 51 203 -1973.000000 9.000000 9.000000 9.000000 9.000000 -2.10800004 -5.36899996 0.22300000 0 51 203 -1988.000000 9.000000 9.000000 9.000000 9.000000 -2.09500003 -5.37099981 0.22600000 0 52 202 -1979.000000 9.000000 9.000000 9.000000 9.000000 -2.08899999 -5.36800003 0.22499999 0 52 202 -1976.000000 9.000000 9.000000 9.000000 9.000000 -2.12100005 -5.36299992 0.22499999 0 52 202 -1996.000000 9.000000 9.000000 9.000000 9.000000

What a great future. We're going to scolded and punished by AI cat ladies.

The reason for this is that on Linux I don't know if it is possible to change the color of a drawn image. I am using XRenderComposite to draw the picture.

Update will be available soon.

This will be fixed in the next update to 1.0.2.

Congratulations. Everyone should try this game.

ChatGPT provides tips on how to cook humans. Basically you can get it to say anything if you add the words "ethical" and "consensual".

The fix will be in the next update for 1.0.2.

Yes, Leadwerks does this. It just requires a displacement map. I have not implemented this in Ultra yet because I want to have an exact definition of how it works.

Well, we could multiply the final output of the terrain system by the overlay color. It might be a good idea. However, you might also want to consider using the the overlay color to control which material appears at which point, and its strength, as you did above. I am not sure which will work out better. I feel like an assigned material would be better...if it looks good. I expect to be trying this fairly soon with my lunar visualization stuff.

How would you suggest blending it?

One of the issues I had was that everything tended to form patterns at 0/45/90/135... degrees, because it only read exact pixel values. Ultra has the Pixmap::Sample method, which uses bilinear filtering, so you take a sample from any angle around the pixel you are working on an get an accurate result.

I am kind of curious to see what these look like. Looks like NASA uses the LAS file format for LIDAR data. https://gliht.gsfc.nasa.gov/index.php?section=34

The reason I like DDS is because it includes the width and height information, and it specifies the pixel format. A 16-bit heightmap, for example, could consist of half-floats or unsigned shorts. With a raw file there's no way of knowing what format it is.

r16 is not an image format. You can do this: pixmap->pixels->Save("Map.r16"); BTW, DDS files do support a variety of formats including floats and half-floats. I've been working with these lately and I think these are my preference. There may be some errors in the current DDS saving code for some formats, though.

You want more, actually. I would probably split them up to a set of 1024x1024 tiles. It's not important to create these now, I am more just investigating to answer some questions for future development.