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
46
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;

47
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

48
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

49
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

50
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 :)

51
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.

52
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 27, 2014, 03:09:49 am »
The problem come from the collision detection system. That's what is making in fact the effectiveness of the body size.

Anyway, whatever the way, the collision detection must be redone if you want to change voxel size.
Increasing the detection distance appeared to be necessary because with some ratio, the player was unable to get voxels just at it's feet.

Quote
...but as a variable it's not been a huge performance hit.

Not only a variable, but also using division/multiplication instead of shifting ... unless you would be limited to power of two ratio.

Sure, it's not huge, but it's always good to avoid when possible.  :)
again .. I didn't change any operators... defined the number of bits a voxels is...
certainly changing just how it's rendered by moving the eye and changing the body size would be a smaller change.

*Shrug*
but voxel size should be a property of a ZVoxelWorld... (like space engineers, the base world is 'Platform' and is aligned square with the universe, other 'worlds' would be implemented for small/large ships which have a translation/rotation matrix associated with them... and a different rendering size)

just played a demo of another game that's voxel based called 'Masterspace' a starforge clone kinda, but with much better game dynamics than starforge ended up with... land is smoothed, but when you re-place blocks you can put them back out as square units, so buildings built with mined resources are square....

53
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 26, 2014, 06:57:56 pm »
Neither of these routines use FaceCulling or 'data' variable associated with the face culling faces... so I think the faceculling save/load isn't working...

Compress_FaceCulling_RLE(UByte*data, void*stream)
{
     ... actual = OtherInfos[p];
}
Decompress_FaceCulling_RLE(UByte*data, void*stream)
{
    OtherInfos[p] = read;
}


54
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 26, 2014, 03:29:13 pm »
Is sector based PartialCulling really worth even having?
How often is an entire side of a thing opaque?
Culling needs to not be a world property; but really more something associated with the renderer; because only the renderer (and save file) is a consumer of cull data.  It certainly makes sense how it currently is that nothing(except game container) knows about the renderer... I started passing the game environment as initializers so classes could get the renderer; and added some culling methods to renderer... but maybe ZVoxelCuller should be a utility class that's associated with/retrieved from the renderer, and then pass that.  ZVoxelCuller would look more like an interface with


ZVoxelCuller( ZWorld &world );

InitFaceCullData( sector );

CullSector( sector, internal/edges);
-or-
CullSectorInternal( sector );
CullSectorEdges( sector );

and CullSingleVoxel( sector, (x,y,z/offset) );

----------------
started ending up with circular references, and things that had static members of thigns like SectorStreamLoader has a SectorCreator, which allocates sectors, and needs the culler (sounds like color)....
----------
I'm enjoying mangling your code :)
I'm going to make some other forks and clean up portions of this, like ZMatrix modification to Camera/PlayerPhysics
---------
also right now; draw_left actually draws the right side; and draw_right draws the right side...
this is a texture labeled according to clipping output...
the letters are oriented up on the sides... and the A for 'above' is up-right if looking from the back to the front.   if you like bypass the 'DRAWFACE_LEFT' there will be a hole for the 'L' side...  either that or forward/backward are reversed... or above/below... if any of these were wrong in the current... render matrix, then the RTFM cube would have backward text on some sides... and an original version does the same thing. (I'm pretty sure.... mine's totally broken right now, going forward with ZVoxelCuller utility class...)
-------------
Disrelated to the thread, but was thinking about other objects... I guess ZVoxelWorld is where I should add a ZMatrix for its current orientation, and give it a small sector size... was going to make ZVoxelSector instances that were standalone for large object models... (an airplane instead of a box with an airplane picture for instance), but maybe it makes more sense to instance worlds

55
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 26, 2014, 11:52:54 am »
I see what you did...
just moving the eye position can shrink the world... but then the player body doesn't match the eye .. and if I have a 2 block hole in a wall I can go through the wall even though my eyes are staring at blocks.

Detection distance.... should stay the same I guess... just has 64x the blocks in the same space...

like I should still be able to dig the same distance as 6 blocks from before... but now it's 24 blocks deep instead

56
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 26, 2014, 10:12:16 am »
Ya but you're shrinking the character too; the point was to add more detail to the world... not just shrink the virtual render size :)  increases the sector count visible though I suppose; but that's just extending the sphere selector thing

It's basically the same mod I did... as a const int variable it's gonna compile away anyway... but as a variable it's not been a huge performance hit.

eye position should be 256

---------
So the inner-sector culling routine is working.... I'm gonna have problems with the inter-sector culling though... the inner-sector had a nice 3x9 block of sectors it was working with... I'm thinking of redoing the seam culling with a 2x3x3 row of voxel references.... need to recover blocks that are near the blocks that are near also...

pretty sure I can do this without the 8 corner cubes in the 3x3x3 set around a point.

was also considering how to implement that culling data is 8 or 32 bits (save version?) but would like to retain so renderer could be applied per sector... but keep the optimal 6 bit culling for render basic...
--------
not sure that a reference looking for Xoffset Yoffset etc is any faster than doing the shifts... since the coorindate has to be shifted to index the array anyway...

57
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 26, 2014, 12:45:01 am »

We have seen in the video that you are using Visual Studio. We assume you are using Gcc/Gdb with it?

The Blackvoxel Team
Nah, using cmake, which spits out makes appropraite for visual studio, I also use open watcom on the side... watcom, gcc and msvc all catch different errors; but cmake allows one make system to support them all...
SDL also uses cmake scripts...
It took a long while; but cmake 2.4 was actually usable.
--------
It's actually not marching cubes...
Was reverting it so I could sway between Render_Basic and Render_Smooth by making most of renderBasic be REnder_Interface, and a virtual 'render' function... but it's just based on existing culling flags
Code: [Select]
if ( ( culling & (FACEDRAW_TOP|FACEDRAW_LEFT) ) == (FACEDRAW_TOP|FACEDRAW_LEFT) )
{
     // example excpetion...
     // if( ( culling & ( FACEDRAW_TOP_HAS_FORWARD| FACEDRAW_LEFT_HAS_FORWARD ) )
     //      == ( FACEDRAW_TOP_HAS_FORWARD| FACEDRAW_LEFT_HAS_FORWARD ) )
     //     // render more complex interpretations
     //  else
     //      //basic, draw  diagonal slope.
}
unfortunately because near sectors aren't always present, and i haven't fixed up the mating clipping updates, on sector boundaries I get false lacking cubes...

and I broke saves because I expended the clipping data from a byte to a long; needed 12 more bits in addition to the original 6 facedraw bits...
and I think I might need all 8 more for the corners ... 26 total... representing the cube of voxels around a center voxel

----------
re the floating land issue; it started showing up when I shrank the block size, so I figured it was just able to see so many more sectors above it that it actually ended up just treating every sector as 'need to fill' ... but it may be a cube that failed to be ejected properly... because again the scale of the world and that doesn't match what it was designed to be..
was just curious if it was something you had seen or something I had messed up... I'll revert some at some point and see what I did.

58
Programming with Blackvoxel / How hard could smoothing be?
« on: October 25, 2014, 02:20:50 pm »
Well... it was a lot harder than I thought...

http://youtu.be/F4AUEHm7BAk

work in progress; maybe

inner corners are unsmoothed... just smooths the outer edges.

Have many corner cases that have multiple solution paths... light right now single blocks and single rows of blocks don't smooth either....

and I have a broken corner that could be better; not to mention all the directions that are yet missing.

was going to map textures on diagonals such that if it's a top & left visible, to show the top and left side of the texture, so the diagonals would get an extra line; right now all left & anything is left and any right & anthing is right and any forward & any is forward and same for back; sorta, top&((right/left)&(back/front)) is top....


59
Suggestions / Re: 3D terrain
« on: October 25, 2014, 02:13:58 pm »

It's a very interesting idea. :)

We will look at the problem.

The Blackvoxel Team
Had a viewer for elevation map that would scroll sub-sections paged in dynamically basically...
had issues mating edges with sectors that didn't load yet... or depending on the order to approach the sector the boundary would be generated differently.... have to save the seems separately I guess.. and even then the diamond square plasma isn't really condusive to that sort of operation....

60
Suggestions / Re: 3D terrain
« on: October 24, 2014, 02:51:05 pm »
I lost some of what I had....
I did have a US national map with elevations in meters in 200x200m resolution; was only like 40M

https://www.sciencebase.gov/catalog/item/4f70a58ce4b058caae3f8ddb

I guess they have 1m resolution now... can add a region type 'external bitmap' or something to the world map...


Why do I get terrain blocks that appear high in the air?  is it cause a sector is 1/4 the size in mine?  I mean what stops the generator from generating sectors that are in the air?

----
at the 200x200m resolution I was going to use the coordinates of the corners and make a plasma grid fill or some perlin noise something...

Pages: 1 2 3 [4] 5