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.

Topics - d3x0r

Pages: [1] 2
I've been toying with smooth meshing for a while, determined to not have to use 'marching cubes'; that surly there's a simpler way.  It's maybe not a 'better' way in all aspects... (pretty pictures included)

(How much TL;DR to include...)
tetrahedra only have 2 mesh modes - 1 point in/out and an edge out which generates a quad that's not constrained  flat.

The example code is JS; and it looks like a lot; the plane mesher (that calculates each shared point only once) is actually simple (perhaps it's because I've been staring at it for dayz).  That is, the first version was long-form expanded with if's; and series of statements; I consolidated those into lookup tables, and 'simplified' the overall required code, at the cost of legibility perhaps?  (Like I never really did understand your face mating tables :) )

This forms a mesh around the points as a center (instead of sort of in-a corner of the cube), which offsets it by (0.5,0.5,0.5); but for things like trees, and other geography would think smoothing would work well, using world-space coodrinates for texture uv-coordinates; was also playing with the ability to 'inflate/deflate' the mesh and realized that meshing water deflated and land inflated would give a very nice transition.

Still requires a pass to stitch sectors together; otherwise data has to be duplicated; can easily do default 'outside' 'inside' by faking 1 render point outside... hmm actually that's just on the stitch line; I should add the stitch pass as another option...

There is certainly a lot of space for square meshes! 

Peace and good health to you!

General Discussion / School Mode
« on: November 01, 2019, 04:11:02 am »
Hello!  Great to see updates from y'all.

School shouldn't be tedious.... Right now, to get to be able to make your first tool... you have to dig, and I'm gussing it's 1.5 seconds(? 2?) per dig block?

( 64 * 3 = 192 ) * 1.5 = 382 seconds... 6 and a half minutes. (9 almost 10 minutes?)

And then I can find greenstone, and be able to return with it to the surface where my machine.

The document says.
'Where can you find it ?
You can find this voxel in the ground into the central blue flat zone.'  And the picture shows it on top of black rock blue... I know it's just showing the same block on the same oroginal blank stage, but... it does sort of imply that it can be over blackrrock blue - and it never is.

So ... I think " it's just another random block like copper, okay I'll keep digging sideways... surely they wouldn't force me to climb up and down all the time... " and dig t alot sideways, so now 30 minutes later and still no greenrock ...

Most voxelish digging games put rock only a little ways below dirt.... 4-8 voxels... because there's an infinite supply of dirt (blackrock blue).

So, optimally that's 6 minutes after the first 5-8 playing with the RTFM and external help; and having the cursor trapped to the game, so I can't click back on the browser... (tough, I know, to own the cursor, but give it up when you don't have it. )  There are lose focus events that you can revert the cursor capture... )

And if I was really new, I'd be sidetracked by copper and iron and other things, and it would really take me a long time to get to green rock; (I mentioned that earlier, it's realistically at LEAST 7 minutes, to make your first tool).

I wanted to learn to program, not spend my time in a clicker.

let me just reiterate, as i was closing this window... I missed the (X) a little...

1) when the game is not in focus, do not setmousepotiion on mouse event.  (background window of the browser, I miss the scroll bar a bit, and my mouse snaps to the other thing, but I was JUST typing in the browser... and then I have to get back to the scrollbar, but if there isn't actually another window over where the mosue moves, it's stuck, until you hit I to get to invenotry (free mouse) or something

2) alt-F4 doesn't work.

3) window isn't resizable by clicking on the frame (if you could somehow get the mouse off the game-focus :) )

So when drilling, if I click and drill, there's a kinda buzzing/grinding sound for the drill.  If I continue to hold the button, that sound stops for the second block.  if I release and click again it re-starts.  (almost shouldn't stop really?)

when holding shift (to run?) the footstep sound stops; and move speed doesn't seem different (if there's supposed to be one)

(Windows 7)

General Discussion / Evolutionary voxel robots?
« on: October 28, 2016, 04:37:27 am »

I ran across this the other day; and you don't have an off topic, and really hope you don't find this too random :)

General Discussion / Voxelarium.js
« on: May 24, 2016, 05:09:12 am »
I got tired of the C# port already :)  (never did finish actually implementing the game portion of it... just water)

Started a new javascript/three.js version...

click and drag; 's' enables moving scaling, it's not very good... faster than scroll wheel though

it's actually broken into separate files on the source side; fed through 'browserify' to make it simple to load on the web page.... but you can save the page and have all the sources; soon to make a github branch for it

(the mode buttons don't do anything any more; I also did a test ... )

(although it's more inspired by, and plajurizing a couple algorithms like sectorSphere :)

General Discussion / Dynamic fonts
« on: November 19, 2015, 06:37:54 am »
I've been tinkering with making a C# port, and was looking for a way to render fonts dynamically instead of having a fixed bitmap font of limited characters.   I stumbled on a C header-only font rendering library which is part of

so I have this class

which uses the c# port of that library and renders characters dynamically into a texture.  (as each character is needed, if it doesn't exist on the bitmap already, render it, copy it to the bitmap, mark the bitmap dirty, then when drawing, if dirty, re-download the image to OpenGL.  Works pretty good...  the GetCharacter routine would have to be changed to support utf-8 decoding instead of utf-16; GetCharacter takes a string and an index and returns  a 32 bit 'rune' named after the character type in Go.

Instead of porting squirrel and the assembly language I was planning on using C# scripts.  I have basic functionality to load .cs files, compile them and use them.  I don't have the reactor done.  so for now it's just a static rendering.  I made a GLSL shader that generates output that look like the general texture with lines on edges... can even control the thickness of the lines dynamically and face/edge color.

Implemented a texture atlas for everything else; but had to scale the images down and extract single faces to fit in an atlas correctly; but was planning on using the texture more as a decal image and the face-edge shader as the background.  So then moved the face/edge colors into the description file.

But; I'm working on interfacing with a physics engine... I was going to use Bullet, even spent some time to make a new C# port of that since the other is obsolete by 3-4 years.... but in the process ended up stumbling on BEPUPhysics which is already C# and has 4-5x the speed of bullet and already supports multi-threaded dispatch of work.   

I also played with the game 'fortresscraft' which is also voxel based and has conveyors/smelters/etc.  Their version makes ore types un-minable by the player, and you attach a drill to a block and get unlimited ore generated from the drill on the ore; kind of unrealistic... but then you can spend time on the automation instead of strip-mining the world...

For now I do very little checking of the C# scripts; but will eventually limit their functionality to just classes the game engine provides and not all of C# library; would be bad to get a script that reads your file system, opens a network connection and dumps all your stuff :)  Or worse... I do limit them now from using 'System.IO' but will eventually need more checks.  Will be nice once MS has compiler-as-a-service support released; can already do it in Mono.

Troubleshooting & Bug Reports / Code Bugs
« on: October 23, 2015, 12:03:33 pm »
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

General Discussion / Similar game?
« 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...
short, quick start... guess this game is pretty deep....
there's lots of other in-play videos

Kinda reminds me of what blackvoxel is kinda attempting to be with automation; different but similar?

General Discussion / General Voxel Performance... no; no it's not
« on: October 07, 2015, 10:28:11 am »
Was going to mention this....
(references )

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

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.

General Discussion / OpenGL Performance
« 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.

Did notice a few articles that OpenGL is faster tha D3D ...

General Discussion / Contrib & Assembler & legacy projects
« on: January 08, 2015, 07:55:40 pm »
it's a 0 not a O ... :)  0:)  :O


Looking forward to assembly...

Omega - (dos box)

c-robots (programming guide)

basically a C syntax... with a limited internal library of 'clib' functions... like
turn(), scan(), ...

My automaton game (bugbrain)  (in zip is 16 bit installer, won't work in 64bit systems)
would add input nodes that are graphic images (chips... actually a chip would be a modular thing, with multiple pinouts on it... an input/output node is more like a pin on a chip/module.... )
Needs a way to register inputs and outputs...
(repackaged as a single zip)

 crobots, omega etc, do active scan... so you have to have a run-loop

bugbrain would be more like a event input... which is more suitable for a ladder-logic sort of language... or PAL language ..

or... FPGA programming (Field-programmable_gate_array) ... but I forget the syntax... and cannot find a good example... It's more like parallel state machines... so a machine has a state, and in a state, when it receives inputs it can generate output and/or change states...

inputs are generally logic signals (read/write BUS line for instance) ... but could be multiple in parallel so (this set of pins is 8 bits) is a address... that can be used to reference lookup tables for outputs...

Programming with Blackvoxel / Custom VoxelTypes
« on: November 09, 2014, 01:26:37 am »
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]

#include "ZVoxelSector.h"
#include "../ZVoxelExtension.h"
class ZVoxelWorld;
class ZVoxelRef
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) );



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;


  if (!Sector) return NULL;

  Offset =  (y & ZVOXELBLOCMASK_Y)

  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;


  if (!Sector) return(-1);

  Offset =  (y & ZVOXELBLOCMASK_Y)


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.
  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 ...
VoxelTypeManager->VoxelTable[VoxelType]->React( ref, LastLoopTime);

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

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))
if( (MemTable[BitPosition] == NewBlock) ? (MemTable[BitPosition]=NewBlock->Next),1:0)

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

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

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

Programming with Blackvoxel / Thoughts on large body collisions?
« on: October 22, 2014, 11:18:13 am »
I ended up breaking collisions by shrinking the world voxel size and keeping the same player size.   I see that you built several planes to represent the character at various levels and an axis through the center.

but with small blocks, 3 or 4 blocks can fit in the spaces... so as long as the voxels that aren't in those planes aren't there, you can pass through it...

So I was considering taking the points of the forward and back planes and iterating through the voxels between them... any thoughts?
Was just now considering instead iterating the central axis and normals along the line.... so the character now is slightly larger than 1 block (6 bits; 64 pixels) so most of the collision stuff works... if I dig a 3 wide 1 deep trench in the ground, it works to keep the feet within it... but if I built bars across the path, can go through a lot. 
Also some single blocks on just the ground I can go through... maybe I end up going around it...

trying to make an argument for only needing to check +/-1 x and +/-1 z from the center axis... character is say 8 blocks high now... would be 40 voxels to check for collision... but only 2 lookups the rest can be iterated through.

Pages: [1] 2