Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - d3x0r

Pages: 1 2 [3] 4 5
31
Programming with Blackvoxel / Re: Custom VoxelTypes
« on: November 10, 2014, 10:17:25 am »

Interesting ideas. We dreamed to make some agriculture and food in blackvoxel since a long time.  But, be careful of animals that could be present in some other voxel games.
Maybe you could make it as some extra terrestrial animals. If you keep reference to some known animals, they could be very different of what we know. In blackvoxel, the idea is that one should be surprised from what he is expecting (when possible, of course).
I agree; was going to make some cyber-space names for them.. but fell back to my idea of foxes and rabbits .... predator/prey and make the foliage be like data nodes... but the concept of growth didn't apply so much... am open to ideas ... maybe 'bit scav'/'virus' and 'antivirus'... so a virus consumes data and anti-virus consumes viruses...

general properties of an 'animal'
health/data size
damage/data consumption
level/entities consumed  (improve damage application effectiveness)
propagation_threshold - if health > threshold spawn new X
age maybe - builtin obsolescence
scent?

----------
Something I've been considering; making transparent voxels have a base voxel extension that can store other voxels... fish in water; animals in plants, animals sharing spots... 1) animals could attack horizontally and just require nearness... 2) animals could be 'on top of' plants... 3) could be a meta voxel type 'fish in water' that behaves like water... but...
Something I'd like to implement is 'smell' that is empty (air) voxels will be like a textureless voxel that's not zero; and contain information about aromas in the air...

normally the player isn't a voxel; so voxels that are player-like should also respect 'can player pass through' ... but then they would be in the voxel.... and since there's only a current reprensentation of a single voxel type in any voxel, it could be an interface implemented on transparent voxels that allow being 'in' the voxel.  Can do a multi-layered render of the voxel at some point to represent the contained voxels... thoughts?  I will assert that from previous experience, I think you'd prefer to keep to a purist approach, and animals will just hop from ground to the top of foliage, and animals can attack animals nearby disregarding height differences.. and then I can't really populate air ... because eventually aroma voxels will exist above fertile land and prevent growth....

Quote

There is a particularity in C++ games : the  operator "new" should be avoided in "game loops" whenever possible because use of the system heap memory manager is always slow (and could lead to massive use causing memory fragmentation problems).
There is no garbage collector like in C# or Java, so that's very different in programming style.
depends on your allocer; most malloc will return the same block as was last freed... so allocating short term storage doesn't fragment.. yes returning into a caller-owned struct solves it.... was more concerned with keeping the function signature the same for quickness; and when not deleted was what was causing my memory error :)  ended up removing that.

well... memory deallocated is defragmented and allowed for reuse; so the things you throw away are collected, so there is garbage collection; just not automagic object reference increment/decrements... and garbage on the stack is collected...

And even so; you still have to intentionally throw away things like Datatables because of the circular references they won't auto implode.... so you should never count on things just going away.

free works kinda like ZMonoSizeMemoryPool::Free such that when released, it's immediately reused for new mallocs...
I find it's better to do a slight more work, and do 2 comparisons in the free list to order free blocks from least memory address to most; further reducing fragmentation... also if the allocer has a minimum memory block size there's less chance of having blocks that are not big enough laying around; my MUD terminal (dekware) improved greatly by setting minimum alloc at 60 bytes... at not that much increase in memory usage.
Also block types that are tiny like binary tree nodes come from a pool of structs so there's only a few allocs from physical memory.

so ya; I saw the techniques and recognized their purpose :) 
----------------------------

And back on aromatics; could do seed dropping too... for vegetation... maybe fertile gruond is just ground until fertilized... I kind of see an evolution of foliage more.. so it's not just that it's A plant that grows, but really the plant type changes... so when it propagates, a 'tall/thick foliage' would cause more thick folliage to grow... that itself being an enemy to the vegetation consumer... I guess the diffusion function would be different for that...



32
Programming with Blackvoxel / Custom VoxelTypes
« on: November 09, 2014, 01:26:37 am »
Success!
I have a block called 'fertile ground' that in a second or 2 from creation grows 'low foliage' aka food.
food will eventually age and become medium and tall; which will be unusable by the first animals... a block called rabbit and a block called fox....
------------
I implemented a type called ZVoxelRef
Code: [Select]
#ifndef ZVOXEL_REF_DEFINED
#define ZVOXEL_REF_DEFINED

#include "ZVoxelSector.h"
#include "../ZVoxelExtension.h"
class ZVoxelWorld;
class ZVoxelRef
{
public:
ZVoxelSector * Sector;
int Offset;
int x, y, z;
UShort VoxelType;
ZVoxelWorld *World;
ZVoxelTypeManager *VoxelTypeManager;
ZVoxelExtension *VoxelExtension;
ZVoxelRef( ZVoxelWorld *world, ZVoxelTypeManager *vtm, long x = 0, long y = 0, long z = 0, ZVoxelSector *Sector=NULL, UShort VoxelType = 0, int offset = 0 )
{
this->x = x;
this->y = y;
this->z = z;
this->Sector = Sector;
this->Offset = offset;
this->World = world;
this->VoxelType = VoxelType;
VoxelTypeManager = vtm;
}
static int ForEachVoxel( ZVoxelWorld * World, ZVoxelRef *v1, ZVoxelRef *v2, int (*f)(ZVoxelRef *v) );

};

#endif

that I for implemented for the result of raycast at maxiter... before I changed method to render selection cube in space in front of player...


// modified GetVoxel which just returned the UShort from a world coordinate
//  to return the World, Sector, relative x,y,z within the sector, and the UShort type
// the sector has it's x,y,z scaled world coordinate... so the absolute coord is knowable from the reference.
... reviewing this a little... the ref could be used for all the temp variables themselves... this actually returns a copy of the world coordinate, React uses it as x,y,z within the sector...
Code: [Select]
inline ZVoxelRef *ZVoxelWorld::GetVoxelRef(Long x, Long y, Long z)
{
  ZVoxelSector * Sector;
  Long Offset;

  Sector = FindSector( x>>ZVOXELBLOCSHIFT_X , y>>ZVOXELBLOCSHIFT_Y , z>>ZVOXELBLOCSHIFT_Z );

  if (!Sector) return NULL;

  Offset =  (y & ZVOXELBLOCMASK_Y)
         + ((x & ZVOXELBLOCMASK_X) <<  ZVOXELBLOCSHIFT_Y )
         + ((z & ZVOXELBLOCMASK_Z) << (ZVOXELBLOCSHIFT_Y + ZVOXELBLOCSHIFT_X));

  return new ZVoxelRef( this, VoxelTypeManager, x, y, z, Sector, Sector->Data[Offset], Offset );
}


inline UShort ZVoxelWorld::GetVoxel(Long x, Long y, Long z)
{
  ZVoxelSector * Sector;
  Long Offset;

  Sector = FindSector( x>>ZVOXELBLOCSHIFT_X , y>>ZVOXELBLOCSHIFT_Y , z>>ZVOXELBLOCSHIFT_Z );

  if (!Sector) return(-1);

  Offset =  (y & ZVOXELBLOCMASK_Y)
         + ((x & ZVOXELBLOCMASK_X) <<  ZVOXELBLOCSHIFT_Y )
         + ((z & ZVOXELBLOCMASK_Z) << (ZVOXELBLOCSHIFT_Y + ZVOXELBLOCSHIFT_X));

  return(Sector->Data[Offset]);
}

-------------
Used this in VoxelReactor to call React virtual method in voxel table...
Code: [Select]
      Long RSx = Sector->Pos_x << ZVOXELBLOCSHIFT_X;
      Long RSy = Sector->Pos_y << ZVOXELBLOCSHIFT_Y;
      Long RSz = Sector->Pos_z << ZVOXELBLOCSHIFT_Z;
  ZVoxelRef ref(World,VoxelTypeManager, 0,0,0,Sector );
    // z, x, y should just be ref.x, ref.y, ref.z, ... redundant copy
      for (z = 0; z < ZVOXELBLOCSIZE_Z; z++)
        for (x = 0; x < ZVOXELBLOCSIZE_X; x++)
          for (y = 0; y < ZVOXELBLOCSIZE_Y; y++)
          {
VoxelType = *(VoxelP);
            if (ActiveTable->Get(VoxelType))
            {
              if (!Sector->ModifTracker.Get( MainOffset ) ) // If voxel is already processed, don't process it once more in the same cycle.
              {
                switch(VoxelType)
                {
default:
  ref.x = x; ref.y = y; ref.z = z;
  ref.Offset = VoxelP - DisplayData;
  ref.VoxelType = VoxelType;

IsActiveVoxels = true;
ref.VoxelExtension = (ZVoxelExtension*)Sector->OtherInfos[MainOffset];
// not sure what St is ...
//St[i]->ModifTracker.Set(SecondaryOffset[i]);
VoxelTypeManager->VoxelTable[VoxelType]->React( ref, LastLoopTime);
break;


33
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: November 09, 2014, 12:46:03 am »

This is a code snippet that's mostly standalone; use of libpng to read/write images.  1/2 is read 1/2 is write.
basically my image stucture is
struct image {
  int x, y;
  unsigned int w, h;
  byte[4] *image; // color data
}


https://code.google.com/p/c-system-abstraction-component-gui/source/browse/src/imglib/pngimage.c

several editors on windows support png and the alpha transparent layer... none (few); probably you use gimp?  support 32 bit alpha saving.  I Have a command line utility that converts 24 to 32; but makes the alpha channel opaque. 

png is like bmp that it is lossless... but it is a zip compression per channel...  works good for RLE encodable images basically... or mostly constant images... but does have 1 byte alpha channel support.

can google 'sample libpng read' which is what my code was based on... which is mostly copy and pastable....

----------
On image loading; I open the file memory mapped and pass the pointer to that memory to a routine that trys passing it to several loader routines, which then result with an image... basically if( !ZBitmapImage.PNGLoad(file) ) if( !ZBitmapImage.BMPLoad( file ) ) ... if (!... JPGLoad() ) ...

can just pass the open file and rewind it between....
SDL has an image loading library...
FreeImage is a LARGE library that loads just about everything... but it's like 2M .. png is a few hundred K
-----------

34
Programming with Blackvoxel / Re: MSVC or non-GCC Porting
« on: November 08, 2014, 10:26:58 am »
Sorry, should be Pointer not 32/64 bit switch...
needed to reverse b and c params and add test if result is the assigned value... not exactly the intrinsic.
Code: [Select]
#ifndef __GNUC__
#    define __sync_bool_compare_and_swap(a,b,c) (InterlockedCompareExchangePointer((void*volatile*)a,c,b), (*a)==(c))
#endif

35
Programming with Blackvoxel / Re: MSVC or non-GCC Porting
« on: November 08, 2014, 07:42:57 am »

Code: [Select]
// in ZTypes.h
#ifdef _WIN32
#    define MANUAL_BREAKPOINT  DebugBreak()
#else
#    define MANUAL_BREAKPOINT  asm volatile ("int3;")
#endif
// #define MANUAL_BREAKPOINT  asm volatile ("int3;")

36
Programming with Blackvoxel / MSVC or non-GCC Porting
« on: November 08, 2014, 06:15:32 am »
Specific to using MSVC instead of GCC to build (or OpenWatcom; although doesn't solve OpenWatcom on Linux)

Code: [Select]
#ifndef __GCC__
#    ifdef __64__
#          define __sync_bool_compare_and_swap(a,b,c) InterlockedCompareExchange64((__int64*)a,(__int64)b,(__int64)c)
#    else
#          define __sync_bool_compare_and_swap(a,b,c) InterlockedCompareExchange(a,b,c)
#   endif
#endif

although as a quick and dirty hack the following code works
Code: [Select]
// in src\z\ZMemPool_Optimized.cpp
#ifdef __GCC__
      if (__sync_bool_compare_and_swap(&MemTable[BitPosition],NewBlock,NewBlock->Next))
#else
if( (MemTable[BitPosition] == NewBlock) ? (MemTable[BitPosition]=NewBlock->Next),1:0)
#endif

which does the same job, but without lock.....

37
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: November 04, 2014, 12:23:39 pm »
I I continued to do some merging, and ... I have gui popup displays rendering... but as soon as I do the textures ...
*and as I typed that I realized what it might have been*
So the last thing that's being done is drawing a black text output, which left glColor set at 0,0,0.. and apparently whatever the last color before the swap is, is what the glCallList lists use... so everything seemed to be there, but it was all black... like the geometry opaqued my displays in the depth buffer... but had no color themselves... finally reset the color back to 1,1,1 before swap and now

.. *deleted*. http://youtu.be/V9TR1w2yEtg

Doh; stupid opengl window doesn't record right.

38
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: November 03, 2014, 09:22:01 pm »
compare_swap_and_xchg and InterlockedExchange are similar; other than the function results...
I see; that is one thing I had an issue with when porting; think I made it thread unsafe...

Here's something I was playing with - surround-o-vision

http://youtu.be/R2izTRpP2kM 

each display is actually independant, and should build its display list appropriate for its view direction, but right now, everything is added to every display list, and 6 windows shown each rendering pass... at very low frame rates there is frame tear between the displays....

More optimal would be to target 3 monitor, and just show forward left and right.. a single display stretched across 3 displays is not right, and perspective gets distorted badly.

----
So ya I'll turn my attention more to voxel based operations... I dunno just feel I'm missing something... like I saw the voxel engine

39
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: November 02, 2014, 09:06:03 am »
The other example of 'poor relationships' I ran into is C# has a type called DataTable, which is a representation of a SQL table, with dynamic columns with types and rows, etc.  But datatables contain columns and rows but all columns know the datatable they are in, and all rows know the datatable, also datatables can be contained in datasets which is a group of datatables and adds the foriegn key relationships between tables.  So from any row you can get to any other row in any other table that row is remotely related to... so there's sometimes merits of having... say worlds know all sectors, but sectors know their world, and hence their renderer...  or something.

40
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: November 01, 2014, 09:40:28 am »

The render code is considered as a critic portion. So adding a function call in a loop should be avoided.

There is 16x16x64 voxels on a sector, so it's making 16384 functions calls.

If the engine needs to render 10 sectors per frame and 60 frames per second, that would do :

16384 * 10 * 60 = 9830400 function calls per second.
True enough.... but it's at least 16 calls that function makes itself... to emit the 4 points with 4 texture coords, setup primitive etc... and that's 1 face of 1 voxel... so figure perfect flatness... 256*16 ... so 1 in 4096 increase in function calls is not significant :)  Edit: I got that a little wrong... If something NEEDs to be inlined... there's always Define's :)   Conveted some of the emitting to defines so I could have consistant texture coord references ... like point 0, face 0,1,2 from it has a texture coord defined for it....

 If a compiler can't do the job 'right' then don't use it...  LCC for instance; wicked fast, but linker cripples real usage.  Wish I could play with icc (intel) but they're so closed for some reason.

It's possible we'll use quaternions in the future, at last for some kind of airplane or rocket that needs to avoid gimball lock. As you said, it could have pro and cons. A lot of stuff could be made without.
For the airplane, fine tuning and balancing it's behavior is a long job. Tuning took in fact longuer than implementing the aircraft itself.
Well Again, quaternions shouldn't be 'used' ... since to be applied for transformation it needs to convert to a 3x3 matrix... might as well just keep the matrix.  linear interpolation only counts for follow cams from arbitrary points to other arbitrary points... but mostly a follow cam will be a relative translation of an existing view camera and not really require quaternion representation either... and the 4 coordinates don't translate into something comprehendable... so expressing any constant quat-vec4's is not really possible... just to retrieve from an existing rotation 3x3 state.... well i,j,k,l vectors work; but once they get combined multiple coordinates change at once for a simple rotation.
-----------------------
But; I guess I'm really looking at the wrong scale of things...
I know you mentioned some things already... but how do I really add a new block behavior?  Maybe creation of a block should create a voxel body :)  A voxel brontasaurus or something... so a simple block spawns all of the others when created... and generate motion in voxel units... was considering a ground displacement for footprints ... so many thoughts.

The bomb in black forest uses world distance for detection and transformation into red liquid distance.... the x64 factor for reduced world size caused much too many red blocks to be created :)

Also attempted to simply add more threads to process things; wasn't as simply extendable as I would have hoped :) 
InterlockedExchange()/*windows, not sure what linux equiv is... gcc __asm...*/... "lock xchg ax, [mem] " is a cheap multiprocessor safe lock.  for things like queues and lists to add/remove items to process, a simple spin-on-lock with a Relinquish() ... sched_yeild() /*linux*/ or Sleep(0); /* windows */ is sufficient and doesn't require things like scheduling.. like if( locked ) sleep( until_lock_is_unlocked ); ..

static size_t lock;  /* register sized variable */
while( locked_exchange( &lock, 1 ) ) { Relinquish(); };
/* do stuff */
lock = 0;

41
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 30, 2014, 07:39:24 am »
Thanx for your long, detailed response.
Speaking of convering to enum...
It is better to use enums for defines... like the set of FACEDRAW_ values can all be assoicated by putting them in an enum; I dunno; maybe it's more useful in C#... then you reference the enum type and all the values you can pick are available in a drop list.  I guess the other reason I started converting defines to enums was for Doc-o-matic code documentation tool; then all the values would be groups in the same documentation page.  To the compiler enums are constants, so there's no performance hit.

I do appreciate the care for optimization during development...it's apparent to me as I was learning where things were.
My only criticism is ... some lines are too long :)  When doing line breaks on long lines, operators should be prefixed on the continuation line and not left on the tail of the prior line... makes reading the expression easier becuase you can see what the op is, inc ase the line is just a little too long; also makes it clear whether a line is a new line (no operator prefix) or a continuation....  This is a habit noone uses or teaches; but I've found of great benefit since early 2000's...

Re: multiple rendering paths... yes, I saw the multiple paths, but the difference is how the voxels are iterated, one uses a foreach(x,y,z) the other uses foreach( in sorted list) and then did the same drawing... so I broke out the triangle emitter into a separate function that both use. 
Code: [Select]
void ZRender_Smooth::EmitFaces( ZVoxelType ** VoxelTypeTable, UShort &VoxelType, UShort &prevVoxelType, ULong info
  , Long x, Long y, Long z
  , Long Sector_Display_x, Long Sector_Display_y, Long Sector_Display_z )
https://github.com/d3x0r/Blackvoxel/blob/master/src/ZRender_Smooth.cpp#L670

Guess I ended up reverting that in ZRender_Basic; so it's back to mostly original code (added culler init)

---------
My issue is... I realize that voxelSector should be a low level class, and not know things like World.. and now after each new ZVoxelSector    another call to InitFaceCullData has to be made... makes it less clean to just get a sector... need like a sector factory in render or world ... one in render could could use one in world.... But then; Render right now is a game(?) a world(?) ... If it was a factory from render, than smooth sectors could be requested or basic...
------
I was having issues getting yaw/pitch/roll reverse calculation working, so I ended up making zmatrix.cpp for those so I could just recompile the one source, since basic types get included by like everything, a change was having to
rebuild everything; need to get rid of .cpp and make the yaw/pitch/roll inlines.  *done*  still some fixups to do in planePhysics I think...
-----
Oh, was playing blackice, and like most FPS they have a pitch lock at +90 degrees... was playin in modified blackvoxel for so long, expected the camera to auto rotate as the angle went over my head.  I'm not 100% sure how this works... and I can't seem to get to exactly 90 degrees up or down, and I'm not sure what would happen if you did get there... since I'm always just a hair to the left or right of exactly down, it results in a roll that undoing results in turning you around in yaw... it's really kinda natural... anyway the snap to 'up' annoyed me yet again... it's not like that actually saves you anything, since you later have to compute sin/cos values to apply motion instead of just having the axis array (matrix) available to use....
I thought quaternions would be way complex; but their usage is really to and from storage, and is a way to smoothly translate one rotation matrix to another through a simple linear interpolation of the quaternaion (which is just a vec4) that can be read/written to the 3x3 rotation matrix.  (matrix is 4x4 cause they have a translation/origin row)... would be nice if d3d and opengl used sane matrixes... layed out so the X/y/z axis normal-vectors are lines up as an array of 3 values so you get the vectors immediately without applying a row-pitch offset thing...
------------
Quote
Yep, that's a more complex algorithm and it needs more sectors. That's a great work.

Full Culling for actual unsmoothed voxels are working with 7 sectors (1 + 6 adjacent).

With need of diagonal voxel data, it will need 27 sectors (1 + 26 adjacent).
but... marching cubes is the 8 bits... which is the 8 corners...  I guess
and I don't need what's diagonal...so the 8 corner cubes from the center... because those don't affect the shape of this or any of the near cubes... so only 18 (6 original, 12 in the 6 ordinals from each of the original 6 ( accessable by 2 names, FRONT_HAS_ABOVE, and ABOVE_HAS_FRONT is the same cube..... but since I don't use the diagonals in the center, then I don't need diagonals from the first mates either... but the I do use 18 bits instead of 8

----------------------------


Glad to meet you :)  don't actually have many peers :)
can I add you on facebook maybe?  I'd share my name, but it's not like John smith... it would immediately indicate a individual so it's like posting my SSN# here :)
Uhmm... I had a TI-99/4a with speech synthesizer (why don't I have a simple speech synthesizer today?)  then several years later a Tandy 1000 (no letters after, original - PC jr clone) and turbo pascal

42
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 28, 2014, 04:29:00 am »
(No worries  about deleted post :) )

I dunno, from an outsider perspective, having a lot of the system developed, like sector paging, allows focusing on detailed things like smoothing.

A brain as a tiny voxel world would only be a few sectors really... and really only rendered in a certain mode...
The brainboard itself has worked for a long time, even had a virtual world ages ago; but lost a lot of code around 2000.  The idea is certainly sound... right now I have just 2d gui's for laying them out... which is even sufficient... I have free-vector renderer even, so can dynaimcally script creating shapes and give them brains.... but; like you mentioned; doesn't do much good if there's no way for people to learn how it works... need tutorial levels for instance... in black voxel; how to make a sequencing conveyor system for instance... saw a conveyor system setup to sequence carbon and metal into furnaces...

I dunno... I have a voxel project I started several weeks ago, but realized there was a lot of managment system around that would have to be implemented... so started looking for source projects... found voxel.js which is a browser based javascript system (javascript!)... was pretty impressive how much performance they got... even a fairly pluggable system...
-------------
Me, I'm a software developer from '84 when I was 12.  I've seen a lot of 'this should be a simple idea' turn into 'that can't be implemented in a reasonable amount of time'  while I've also seen things that seemed really complex turn into less than 2 line code change.. But I'm more in the practice of implementing before fully fleshing out; if the skeleton doesn't work at all, not much use in fleshing it out.  And I remember when CPUs were all there was, and they weren't all that fast, and had 3d rendering code back then that was decent... then 3DFX game out with Glide, and things looked better, then nVidia bought them and killed Glide.  Which made me hate nVidia for a long time... I did notice that these opengl display lists are amazingly fast.  Probably going to take that and port it to my opengl 1 display layer... for opengl2 I was building vertex buffer object things, but with display lists it would record the change in textures too... had to build vertex buffers for each source texture (or texture combination)...  But; I've even hand coded assembly for optimization... although even the slowest processors today make it unnessecary for presentation/interaction purposes that I've let most of that code fall by the wayside about the time 64 bit processors came out... most compilers do clever optimizations.... but I'm well away of the difference between accessing a pointer/reference and just having a thing there... and the additional lookups required for what might on the surface seem like a simple operation... Every line is often written with 'is there a way to make this cheaper?' in mind...  Voxel engines definatly benefit from having memory resources, and doesn't require as much optimization as once upon a time (64k was tough to do much, 640k seemed like infinite memory... until it wasn't... )... but anyway; I'm certainly not a noob when it comes to development...

-----
Okay So I've associated a ZVoxelCuller_Basic:ZVoxel_Culler with ZRender_Basic and a ZVoxelCuller_Smooth:ZVoxel_Culler with ZRender_Smooth...

Code: [Select]
class ZVoxelCuller
{
protected:
   ZVoxelWorld *world;
public:
ZVoxelCuller( ZVoxelWorld *world )
{
this->world = world;
}

void SetWorld( ZVoxelWorld *world )
{
this->world = world;
}

virtual void InitFaceCullData( ZVoxelSector *sector ) = 0;

// if not internal, then is meant to cull the outside edges of the sector
virtual void CullSector( ZVoxelSector *sector, bool internal ) = 0;

virtual void CullSingleVoxel( ZVoxelSector *sector, int x, int y, int z ) = 0;

// get a single voxel's culling (copy sector); ULong value used even though some culling only uses 6 bits
virtual ULong getFaceCulling( ZVoxelSector *Sector, int offset ) = 0;
// set a single voxel's cullling (copy sector)
virtual void setFaceCulling( ZVoxelSector *Sector, int offset, ULong value ) = 0;
// Load culling from a stream
virtual bool Decompress_RLE(ZVoxelSector *Sector, void * Stream) = 0;
// save culling to a stream
virtual void Compress_RLE(ZVoxelSector *Sector, void * Stream) = 0;


};
The problem was; implementing this means changing after each place that does a 'new ZVoxelSector' to init the culling... for instance the static working sectors...
it's all rather hideous... and maybe I should drop the whole thing... but probably won't but temporarily
Code: [Select]
ZFileSectorLoader::ZFileSectorLoader( ZGame *GameEnv )
{
this->GameEnv = GameEnv;
SectorCreator = new ZWorldGenesis( GameEnv );
  ReadySectorList   = new ZSectorRingList(1024*1024);
  EjectedSectorList = new ZSectorRingList(1024*1024);
  SectorRecycling   = new ZSectorRingList(1024*1024);
  VoxelTypeManager = 0;
  UniverseNum = 1;
  WorkingEmptySector = new ZVoxelSector;
  GameEnv->Basic_Renderer->GetCuller()->InitFaceCullData( WorkingEmptySector );
  WorkingEmptySector->Fill(0);
  WorkingFullSector = new ZVoxelSector;
  GameEnv->Basic_Renderer->GetCuller()->InitFaceCullData( WorkingFullSector );
  WorkingFullSector->Fill(1);
  Thread = 0;
  ThreadContinue = false;
}

which the moves code from ZVoxelWorld to an implementation of the virtual interface, then set the interface per sector.... added a ZVoxelCuller *culler; next to void *FaceCulling;

----------------
Nuts and bolts out of the way...

was thinking about how to implement reasonable alogrithms for culling... since corners will now need diagonal sectors to get information.

so... culling internal works
culling external should be broken into 3 parts... the face... if PartialCulling is set, process the inset face, without edes and corners.
Edge cubes should get updated when any of the other near three sectors get added... I guess only a subset of bits have to be set;
And corner cubes...

if I portion it out that way should simplify some iterations...

The basic culler should use a staggered cube algorithm... then only 50% of the cubes have to be checked...

Other thoughts I pursued a while ago was to make like a surface interface between cubes and non-cubes... so solid things wouldn't have to be considered... kinda similar to what sorted render does... that a list of 'interesting' voxels is produced.... but similar to the face conglomerating idea; it ends up causing more work than benefit in sparsely populated voxel sectors... although a normal landscape would basically boil down to 256 interesting points per sector... for a normal terrain mesh.. a few extra points for steep hills...

just musing

43
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 28, 2014, 12:39:27 am »
(No worries  about deleted post :) )

I dunno, from an outsider perspective, having a lot of the system developed, like sector paging, allows focusing on detailed things like smoothing.

A brain as a tiny voxel world would only be a few sectors really... and really only rendered in a certain mode...
The brainboard itself has worked for a long time, even had a virtual world ages ago; but lost a lot of code around 2000.  The idea is certainly sound... right now I have just 2d gui's for laying them out... which is even sufficient... I have free-vector renderer even, so can dynaimcally script creating shapes and give them brains.... but; like you mentioned; doesn't do much good if there's no way for people to learn how it works... need tutorial levels for instance... in black voxel; how to make a sequencing conveyor system for instance... saw a conveyor system setup to sequence carbon and metal into furnaces...

I dunno... I have a voxel project I started several weeks ago, but realized there was a lot of managment system around that would have to be implemented... so started looking for source projects... found voxel.js which is a browser based javascript system (javascript!)... was pretty impressive how much performance they got... even a fairly pluggable system...
-------------
Me, I'm a software developer from '84 when I was 12.  I've seen a lot of 'this should be a simple idea' turn into 'that can't be implemented in a reasonable amount of time'  while I've also seen things that seemed really complex turn into less than 2 line code change.. But I'm more in the practice of implementing before fully fleshing out; if the skeleton doesn't work at all, not much use in fleshing it out.  And I remember when CPUs were all there was, and they weren't all that fast, and had 3d rendering code back then that was decent... then 3DFX game out with Glide, and things looked better, then nVidia bought them and killed Glide.  Which made me hate nVidia for a long time... I did notice that these opengl display lists are amazingly fast.  Probably going to take that and port it to my opengl 1 display layer... for opengl2 I was building vertex buffer object things, but with display lists it would record the change in textures too... had to build vertex buffers for each source texture (or texture combination)...  But; I've even hand coded assembly for optimization... although even the slowest processors today make it unnessecary for presentation/interaction purposes that I've let most of that code fall by the wayside about the time 64 bit processors came out... most compilers do clever optimizations.... but I'm well away of the difference between accessing a pointer/reference and just having a thing there... and the additional lookups required for what might on the surface seem like a simple operation... Every line is often written with 'is there a way to make this cheaper?' in mind...  Voxel engines definatly benefit from having memory resources, and doesn't require as much optimization as once upon a time (64k was tough to do much, 640k seemed like infinite memory... until it wasn't... )... but anyway; I'm certainly not a noob when it comes to development...

-----
Okay So I've associated a ZVoxelCuller_Basic:ZVoxel_Culler with ZRender_Basic and a ZVoxelCuller_Smooth:ZVoxel_Culler with ZRender_Smooth...

Code: [Select]
class ZVoxelCuller
{
protected:
   ZVoxelWorld *world;
public:
ZVoxelCuller( ZVoxelWorld *world )
{
this->world = world;
}

void SetWorld( ZVoxelWorld *world )
{
this->world = world;
}

virtual void InitFaceCullData( ZVoxelSector *sector ) = 0;

// if not internal, then is meant to cull the outside edges of the sector
virtual void CullSector( ZVoxelSector *sector, bool internal ) = 0;

virtual void CullSingleVoxel( ZVoxelSector *sector, int x, int y, int z ) = 0;

// get a single voxel's culling (copy sector); ULong value used even though some culling only uses 6 bits
virtual ULong getFaceCulling( ZVoxelSector *Sector, int offset ) = 0;
// set a single voxel's cullling (copy sector)
virtual void setFaceCulling( ZVoxelSector *Sector, int offset, ULong value ) = 0;
// Load culling from a stream
virtual bool Decompress_RLE(ZVoxelSector *Sector, void * Stream) = 0;
// save culling to a stream
virtual void Compress_RLE(ZVoxelSector *Sector, void * Stream) = 0;


};
which the moves code from ZVoxelWorld to an implementation of the virtual interface, then set the interface per sector.... added a ZVoxelCuller *culler; next to void *FaceCulling;

----------------
Nuts and bolts out of the way...

was thinking about how to implement reasonable alogrithms for culling... since corners will now need diagonal sectors to get information.

so... culling internal works
culling external should be broken into 3 parts... the face... if PartialCulling is set, process the inset face, without edes and corners.
Edge cubes should get updated when any of the other near three sectors get added... I guess only a subset of bits have to be set;
And corner cubes...

if I portion it out that way should simplify some iterations...

The basic culler should use a staggered cube algorithm... then only 50% of the cubes have to be checked...

Other thoughts I pursued a while ago was to make like a surface interface between cubes and non-cubes... so solid things wouldn't have to be considered... kinda similar to what sorted render does... that a list of 'interesting' voxels is produced.... but similar to the face conglomerating idea; it ends up causing more work than benefit in sparsely populated voxel sectors... although a normal landscape would basically boil down to 256 interesting points per sector... for a normal terrain mesh.. a few extra points for steep hills...

just musing

44
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 27, 2014, 08:52:31 pm »
Kinda off topic

a game before minecraft; resurrected...

http://gamasutra.com/view/news/228123/Infinifactory_and_the_next_generation_of_the_Minecraft_genre.php

http://www.zachtronics.com/infinifactory/

has conveyor system

I dunno the other thing I'm working towards is a visual pgrogramming language... Alice is close to usable
http://www.alice.org/index.php

someday there will be a game that is one game to rule them all.  that should be my signature :)

45
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 27, 2014, 03:19:43 am »

Does culling must be done at world level ? In some parts, sectors need to be processed independently to the existence of a world.  So, your proposition of an independent class is an efficient idea to clean the mess.

But we are tempted to say : don't mangle your head too much with that.

Because what is on our roadmap for future is making face culling completely integrated with rendering phase.

Yes, making that could be a very, very bad choice in some ways because it can add significant overhead to the main thread.

So, why we plan to do it ? Let's explain the actual system and why it could be better.

Keep in mind that Blackvoxel made very specific game choices. It's MVI engine cause massive load on rendering. Also, vehicles like airplane needs very quick refresh of sectors.

The Blackvoxel Team
Right; it looks like something that should be part of the render path, with the same dirty flags, so if the display lists are built already, just run those, otherwise do the required updates.

Also, the game is maxed at 17-19%... would be interesting if more threads could be started to process things like water.  looks like there's only 1... and the renderer doing work.

Re the PartialCulling... when it comes time to check the edges... Oh I see... partial culling is cleared as near sectors are found so it doesn't have to do all sides every time a new near sector is added.

Pages: 1 2 [3] 4 5