[RGBA to Float]

intBitsToFloat()

Funny how simply making a post can make the answer show up on your next google search. 

[RGBA to Float]

I have packed integers and floats into a texture to use in my shader.  Information is packed into the texture by poking a buffer and then assigning that buffer to an RGBA texture.  The following code extracts an integer from a texelFetch result in the fragment shader.  It seems to work well.

int BytesToInteger( in vec4 pixel ) {
	return ( int( ( pixel.w * 255.0f ) ) << 24 ) | ( int( ( pixel.z * 255.0f ) ) << 16 ) | ( int( ( pixel.y * 255.0f ) ) << 8 ) | int( ( pixel.x * 255.0f ) );
}

However the same process does not work for floats and I'm sure there is a reason why but I can't figure it out.  Any one know the answer? 

float BytesToFloat( in vec4 pixel ) {
	return float( ( int( ( pixel.w * 255.0f ) ) << 24 ) | ( int( ( pixel.z * 255.0f ) ) << 16 ) | ( int( ( pixel.y * 255.0f ) ) << 8 ) | int( ( pixel.x * 255.0f ) ) );
}

 

[Multiple Materials]

I may not be correct but it might be this I need -

material->render_material->id;

 

[Multiple Materials]

On 2/25/2023 at 6:26 PM, SpiderPig said:

Through brief trial and error I got this example to work.  I want to be able to get the materials index so I can retrieve multiple materials in the shader for my voxel terrain.  I can find a way to send the materials indexes I need to the shader, that shouldn't be a problem.  (I'll probably use a small texture to hold the index)  It's just actually getting the material index.  Something like this perhaps?

material->GetIndex()

My C++ Code:

Is this possible yet?

 

[Package::LoadDir("") returns nothing on large package]

I wonder if that will solve this issue or of there's something else at play...

[Package::LoadDir("") returns nothing on large package]

3 hours ago, Josh said:

Libzip probably does not either:
https://github.com/nih-at/libzip/issues/239

In this link the guy reckons it does actually work on 64 bit machines... just not on 32bit.  To me that makes sense that a 32bit machine can't load something bigger than 4GB but I'm no expert.

Quote

Note that the same code (same libzip version, same ZIP file) works correctly on 64-bit devices. I checked on both AMD-64 and ARM-64.

 

26 minutes ago, reepblue said:

The library that 7z uses should be apart of ziplib unless Josh excluded it.

I did try loading a 7GB ".7z" file just to be sure but it didn't load.  I don't know much about 7z, it uses LZMA or something?  Maybe this SDK is what I need to make a 7z plugin.

https://www.7-zip.org/sdk.html

But I don't know, maybe libzip has a bug with loading over 4GB files...

[Package::LoadDir("") returns nothing on large package]

Yeah probably.  It's defiantly a zip.

[Package::LoadDir("") returns nothing on large package]

If this is a limitation if zlib then this might be an opportunity for a 7zip plugin. 

[Package::LoadDir("") returns nothing on large package]

I've just confirmed ReadFile() returns nullptr too.  The package seems to load okay - well there's no errors and it's not nullptr.

[Package::LoadDir("") returns nothing on large package]

13 minutes ago, Josh said:

https://comp.lang.idl-pvwave.narkive.com/L2ukAnN1/zlib-uncompress-limited-to-4gb

I compressed it with 7zip, it's interesting that last comment saying it's not a zip?  Even though it is... and I've compressed large files with window's default zip too and it worked above 4GB.

Anyway, I can open the 7GB in windows explorer to search the files and I can extract from it.  Don't know any other software besides 7zip to try it with...

[Package::LoadDir("") returns nothing on large package]

So 4GB was a limit in the past?  So it should work now...?

[Will the engine be source available.]

I don't think it will be.  

[Package::LoadDir("") returns nothing on large package]

I've compressed 5,259 4096x4096 r16 heightmap files into a zip file.  It's about 7GB of data.  Using LoadDir("") to list the files at the root returns a size of 0 ONLY for this zip file.

I used the code below on a zip file of 5,259 1024x1024 r16 heightmaps (1.2GB) and it worked fine.  Pretty sure all the files have the exact same names in both zip files.  It's just the map resolution that is different.

I thought maybe LoadDir() or LoadPackage() doesn't like the large zip file?

 

This is the snippet of code that handles the loading.

if (extension == "zip") {
	auto package = LoadPackage(filepath);

	if (package != nullptr) {
		auto dir = package->LoadDir("");

 

[Parents keep children alive]

I've probably asked this before but just want to check... should a parent keep its child alive?  This is the only way to delete an entity with a parent.

entity->SetParent(nullptr);
entity = nullptr;

 

[Streaming Voxel Terrain]

Been working on streaming voxel terrain and I'm pretty happy with the results so far.  Nearly completed the streamer class.  Each tile below is a 1024x1024 r16 heightmap.  The area in view is about 50km2.  The red tiles are tiles I've removed from the dataset because each pixel in those maps are zero (below the water surface).  The test data set I made is a grid of 120x120 tiles which was 14,400 heightmaps files.  However after removing all the tiles that were of zero height it became about 5,600 tiles.  About 10GB all up.  Should be able to compress that in a zip but will need to do more testing yet... was giving mixed results.

Simple to set up. 

void CreateStreamingVoxelTerrain() {
	voxel_brush = CreateVoxelBrush();
	voxel_brush->SetSurfaceFunction(CalculateTerrainSurface);

	voxel_world = CreateVoxelWorld(world, 1024, 16.0f, 7);
	voxel_world->EnableStreaming(true, "Maps\\Data");
	voxel_world->SetDimensions(490000.0f, 1617.0f, 490000.0f);
	voxel_world->FlipY();
	voxel_world->AddBrush(voxel_brush);
	voxel_world->AddObserver(camera);

	voxel_world->DrawVoxelObjectBounds();
	voxel_world->DrawPatchBounds();
	voxel_world->DrawBounds();
}

 

[View files inside zip file?]

Is it possible to use LoadDir() on a zip file and see what files are inside it?  I want too loop through all the file names inside the zip file.

[Indicator which Project is currently open in the editor]

You only see it when you click on the project tab.  The title bar seems the best place for it because it's always visible and most other software's have that too.

[Thumbs view]

Working for me okay.  I'm on the dev branch.  Is that the latest?

[Editor Camera Position Not Saving]

When ever I load a map the editors camera position is always back to zero.  Shouldn't it be at the last place when the map was saved?

[Culling seems to get slow quickly]

I've noticed this too.  It's been like this for a while, especially in DEBUG mode.  I think it's because of the separate rendering thread.  Pretty sure Josh said a fix is planned.

[Auto load last opened map]

I see the editor loads the last opened project and it would be nice to see it load the last opened map file associated with that project too. 

[Terrain Splat Maps]

That's terrific thanks!  I'll get into it this week.

[Editor Render View Turns White in 3D Perspective]

4 hours ago, Leag said:

I tested the other three viewports as well, and switching to the 3D viewport doesn't turn them white. However, the issue seems to be exclusive to the 3D viewport—changing it to top/back/right/left, and then switching back to 3D, triggers the white background.

In the other 3 viewports did you try switching back and forth between 3D at least twice?  That did it for me.  Default -> 3D -> Front -> 3D = white.

[Editor Render View Turns White in 3D Perspective]

I just tried this too and get the same bug.  I tried the other 3 viewports as well.  Switching from their default view to another ortho view doesn't do it.   Even switching from ortho to perspective doesn't do it.   But if the viewport has been perspective at some point, switching to perspective again at some point makes the viewport white.  Actually in my case black but then white when I click inside it.

I have GTX 980 TI + Windows 10.

[Polyhaven Browser Extension]

Seems to be working now.  Thanks.