Recent Posts

Pages: 1 ... 8 9 [10]
91
Troubleshooting & Bug Reports / Re: Code Bugs
« Last post by Enigma on October 25, 2015, 12:58:22 am »
hi, d3x0r,

Thank you for finding this bug. This one could have made problems.  :o

I should also check other face culling functions : in Blackvoxel, this work is distributed among several modules in several threads.

This function (ZWorld::SectorUpdateFaceCulling()) is dedicated for cases where a complete sector needs to get a full face culling.

A little summary about Face culling in Blackvoxel...

The birth of sectors occurs in the ZFileSectorLoader object powered by a dedicated thread. After creation or loading, the face culling of the sector core voxels are computed using ZFileSectorLoader::LimitedUpdateFaceCulling(). Sector's external faces aren't done : at this point, the sector isn't integrated to the world(the concept of world isn't yet existing), so data are missing to compute face culling for boundaries : neighboring sectors are needed for that.

Further, sectors are integrated to the world by the main thread. But remaining culling is done by a third thread along with the MVI engine. When some inter-sector face culling is remaining to do (Indicated by the multi bit field ZVoxelSector::PartialCulling), it's done by the ZWorld::SectorUpdateFaceCulling_Partial() function. This function is doing the face culling link between sectors and can do selective work side by side as soon as some neigboring sectors become availlable.

Some face culling is also done in ZWorld::SetVoxel_WithCullingUpdate() when individual voxels are modified.

The Blackvoxel Teams.
92
Troubleshooting & Bug Reports / Code Bugs
« Last post by d3x0r on October 23, 2015, 12:03:33 pm »
ZWorld.cpp
void ZVoxelWorld::SectorUpdateFaceCulling(Long x, Long y, Long z, bool Isolated)

  UByte * BlocMatrix[3];

This is only a byte, but it's using Sector::Data which is UShort now.

This is OK because there's only 238 types right now.... but will be a problem with voxel type 256 ... or type&0xFF == 0

93
General Discussion / Re: General Voxel Performance... no; no it's not
« Last post by Enigma on October 10, 2015, 02:40:31 am »
Was going to mention this....
http://www.volumesoffun.com/implementing-morton-ordering-for-chunked-voxel-data/#more-1755
(references https://en.wikipedia.org/wiki/Z-order_curve http://www.forceflow.be/2013/10/07/morton-encodingdecoding-through-bit-interleaving-implementations/ )

Basically I was playing with unity, and found there's a free voxel engine plugin.  Developed by the same people that did Polyvox.  And saw that article, and after reading the articles thought 'wow maybe that would be nice'

My first test case it turned out the the max distance from (-1,-1,-1) to (1,1,1) was 53.  (even smaller than the 256 that is the distance from (0,-1,0) to (0,0,0) in black voxel)  Which would mean that it would be even better for locality of voxels in cache.

However; that was just 1 case, and the real worst case is a distance of 3080(!). 
7,7,7 center
min 504   00000000000000000000000111111000
max 3584 00000000000000000000111000000000

.....No
The worse case gets worse and worse.... iterating over 0-100,0-100,0-100 the average max distance is 41296(!)

Each point at 7, 15, 31, 63, is increasingly large offset...

-----------------
So ya; ignore this.

this is more of a what-not-to-do.... it looks clever to start... but having reasonably sized sectors is more advantageous... and does nothing but complicate the offsets to wrap between sectors.

On a quick analysis, I guess there could be some advantages if most access on the grid were random and combined with systematic access to neighboring voxels.

But that's not the common case in Blackvoxel. So you are right. That would be a false good idea (at least for this particular game).

Anyway, that's interesting to see some ideas trying to make improvements  ;).

The Blackvoxel Team
94
General Discussion / Similar game?
« Last post by d3x0r on October 08, 2015, 12:56:43 pm »
don't mean to promote it; maybe it will be some inspiration?

Stumbled on this other game...
https://www.factorio.com
short, quick start... guess this game is pretty deep....
https://www.youtube.com/watch?v=sMgtUxpGlPc
there's lots of other in-play videos

Kinda reminds me of what blackvoxel is kinda attempting to be with automation; different but similar?
95
General Discussion / General Voxel Performance... no; no it's not
« Last post by d3x0r on October 07, 2015, 10:28:11 am »
Was going to mention this....
http://www.volumesoffun.com/implementing-morton-ordering-for-chunked-voxel-data/#more-1755
(references https://en.wikipedia.org/wiki/Z-order_curve http://www.forceflow.be/2013/10/07/morton-encodingdecoding-through-bit-interleaving-implementations/ )

Basically I was playing with unity, and found there's a free voxel engine plugin.  Developed by the same people that did Polyvox.  And saw that article, and after reading the articles thought 'wow maybe that would be nice'

My first test case it turned out the the max distance from (-1,-1,-1) to (1,1,1) was 53.  (even smaller than the 256 that is the distance from (0,-1,0) to (0,0,0) in black voxel)  Which would mean that it would be even better for locality of voxels in cache.

However; that was just 1 case, and the real worst case is a distance of 3080(!). 
7,7,7 center
min 504   00000000000000000000000111111000
max 3584 00000000000000000000111000000000

.....No
The worse case gets worse and worse.... iterating over 0-100,0-100,0-100 the average max distance is 41296(!)

Each point at 7, 15, 31, 63, is increasingly large offset...

-----------------
So ya; ignore this.

this is more of a what-not-to-do.... it looks clever to start... but having reasonably sized sectors is more advantageous... and does nothing but complicate the offsets to wrap between sectors.
96
General Discussion / Re: OpenGL Performance
« Last post by Enigma on October 03, 2015, 02:49:24 am »
OpenGL performance improvements... requires a pretty advanced OpenGL Level?  But some of it is interesting in pointing out that there might be more.
http://blogs.nvidia.com/blog/2014/03/20/opengl-gdc2014/

Did notice a few articles that OpenGL is faster tha D3D ...
http://www.extremetech.com/gaming/133824-valve-opengl-is-faster-than-directx-even-on-windows

Hi d3x0r, glad to see you :)

Thanks, I'll look at that. It seem very interesting.

This move of the graphic industry in driver overhead reduction is really positive.

As you know, that's especially true for a game like Blackvoxel because of it's massive playfield refresh.

With the new API generations, they are also moving on a more low level approach, which mean (at least in theory) more flexibility. And maybe (I hope) something better suited for the particular case of rendering voxels.

We also hope the new Vulkan API will be as good as the promises.
97
General Discussion / OpenGL Performance
« Last post by d3x0r on October 02, 2015, 09:03:57 am »
OpenGL performance improvements... requires a pretty advanced OpenGL Level?  But some of it is interesting in pointing out that there might be more.
http://blogs.nvidia.com/blog/2014/03/20/opengl-gdc2014/

Did notice a few articles that OpenGL is faster tha D3D ...
http://www.extremetech.com/gaming/133824-valve-opengl-is-faster-than-directx-even-on-windows
98
Suggestions / Re: Website css
« Last post by Enigma on August 17, 2015, 02:28:08 am »
Hello MUY_Belgium and welcome to the Blackvoxel forum  :)

Tank you for this useful suggestion.

Thats done !

If your computer have modest hardware, don't forget to take a look at our optimization tutorial :
https://www.blackvoxel.com/view.php?node=1248

In particular, in the Settings_Hardware.dat file, two fields can have a tremendous effect : RenderingDistance_Horizontal and RenderingDistance_Vertical.

By lowering the values on these two fields, we managed to run Blackvoxel on a monocore atom netbook with only 1gig Ram(and GNU/Linux).

The Blackvoxel Team
99
Suggestions / Website css
« Last post by MUY_Belgium on August 16, 2015, 12:26:02 pm »
Hello,

I have experimented some difficulties, because my computer is not powerful enough to sustain the game fullscreen and the browser at the same time.  I have to exit the game to read the help.

I rather print the help to get on-game help (I know not a good practice !).

If the following code is added to /look/css/default.css , the unnecessary context menu would not get printed any more.

Code: [Select]
@media print {

li.rightcolumn       { display:none; }
div.plotvente        { display : none; }
div.mdbox_02         { display : none; }
div.footerlinks      { display : none ; }

/* remove space for non-visible page header */
ol.tabmenu           { display:none; }
div.contentpagetitle { display :none;}

/* Use all the available space on page */
li.middlecolumnwide { width : 100% ; }
}

see http://www.w3schools.com/css/css_mediatypes.asp for more informations.

Possibly, setting the width of li.middlecolumnwide may not be a good idea.
100
General Discussion / Re: OSX port
« Last post by d3x0r on August 02, 2015, 11:21:28 am »
Re Deprecated register keyword...

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4340.html
http://stackoverflow.com/questions/10675072/is-the-register-keyword-still-used

I personally disagree that this should be deprecated... but apparently has, and will be removed in C++17.
There are certainly more ideally things the compiler can't figure out, and doesn't. I've seen worse and worse code generation by more modern compilers than things in the mid 90's. 

The argument goes like 'it was only a hint, and the compiler has register coloring anyway so it's meaningless.' but I've seen little effort by the compiler to preserve values in registers, mostly because by nature it assumes things are 'volatile' so it reloads them (I guess, can't otherwise figure why just bad code would be generated).

I certainly don't want people to go to inline assembly for something so simple since that's far from portable between compilers... this really all makes me sad.

Pages: 1 ... 8 9 [10]