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

Pages: 1 2 [3] 4 5 ... 10
31
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 27, 2014, 11:53:50 pm »
Quote from: d3x0r on October 27, 2014, 09:27:56 am
so... entites will always just be a single voxel then?  maybe 2 if it's aplayer ? so no making like a large animated dragon/samauri ICE? (intrusion countermeasure electronics from Shadowrun/Cyberpunk matrix)... hmm hard to show what I mean it's just a image in mind, and a rough search returns 0 results that are even similar... something like http://superdupergc.com/?p=221  ... but I guess other models don't have to be voxel based...  kinda the inverse of robocraft, where landscape is just a mesh, and the entities are all voxel...

Yes you can animate large block structures in Blackvoxel  :). A single MVI active voxel can animate a lot of voxels.

But, yes, that's not similar to games having entities whether these are vector or voxel entities.

The problem with entities is that they can't interact with the world the same way the voxel does.

So, that's a particular design choice in Blackvoxel to replace entities by true voxels.

That's what we mean by "pure voxel paradigm".

Of course, that choice mean Blackvoxel can't do what a lot of voxel gamesdoes with entities.

But it also mean we can do some things other games can't.

That's what we can call a choice   ;).

I take this opportunity to say that Black Ice get out a long time after Blackvoxel.

Quote
I'm not attempting to make it be something else... I'm just noting where others have already made some interesting mods.... and some of them would really be fairly easy to accomplish.

Was actually heading more towards making a micro scale world to represent the neural networks... which would be within a robot cube for instance. ... and although it doesn't really need a orientation, it would be useful to add an offset-origin to it; and might as well just add orientation while at it.

Why not creating an abstraction with an "ai" robot that will scan a portion of world where you create your design and copy it internally for execution?

Quote
You keep speaking of this 'road map' but I didn't see it.... may be I didn't look hard enough, but in the early beginning was looking for such information...

So, lets explain what's is our vision and roadmap.

Blackvoxel started in 2010. Engine and all parts around take a big amountof time. After two years, we froze engine capabilities, developed content and stabilized the whole stuff.

Since Blackvoxel has enough content to be played, we completely got out of alpha and beta state and entered in full stable state. Blackvoxel is now stable since a while.

This state won't mean development stopped, but rather that stability became a strong priority over new engine features. When users have some issues, we try to do our best to quickly fix them. The more stable it is, the less time it take to make support over developing time.

Now, our roadmap is focused on game content, educational materials and other kind of stuff around the game. Game contents like new voxels, automatics, robots, zones, etc, are now the main priority of the project. Doing things differently would be very difficult.

At this time, making engine evolution is not a priority: it's working very well. It's stable, it's fast. And there is now a lot to do with stuff it does. (We know there is some cleaning to do in it. We'll try to do our best in the time.)

So we'll try to minimize changes on it to keep stability, but also for best usage of our limited resources: it would be nonsense to have a wonderful engine with no game and no content.

That won't mean that we'll do no evolutions on the engine. But rather that evolution will be well planned in long term evolutions with  careful changes to avoid stability problems.

Of course we can decide to change this if one day we found it's interest of the project.

But for now, there is a lot of things to do with what we have already.

Quote
I also played with 'Seed of Andromeda' which has a good approach for modelling full dynamic planets, also with a sub-meter voxel.... They have no smoothing, and I inquired, and they said 'it's an artistic choice we make to set ourselves apart' ... looks more to me like it's a choice that makes them like everyone else... it's more rare to have smoothing than to have minecraft cube model.... but they do have cute explosions when voxels are removed... with persistant particles such that they can be picked up later... or you can break a dirt block and get gems out or something based on sub-portions of the material being able to be different result types.  They also didn't think neural networks would be within their scope either... even within the scope of supporting as a external Mod; even though the creator's like 'allow modders to do anything they want'... *shrug* Or better to have dynamic choice on whether a voxel is smoothed (can use a single bit in the 16 for
VoxelType for instance, and still leave 32000 types of cubes ) ... and iterating up the relations, smoothing per voxel-sector, smoothing per world... (landscape and constructions based on top of it being separate worlds, within the same universe).

In fact, voxels are very old concept. We found early kinds of voxel game at the early 80. Even smoothed voxel are old : marching cube patent was published in 1985. If you want to see a Minecraft looking game that have more than 15 years old, TurboLode, it's here.
Voxel game where 3D evolutions of 2D tiled games. But the vector game fashion lead to forgot them for a long time. That wasn't the only reason: voxels are memory hungry.
But with modern hardware and it's huge memory along with vector game boring, that was only a question of time for voxel game to come back.

We can understand why some creators prefer to use non smoothed voxels.

Smoothed voxels can get more visual friendly on engine that are focused on this.

In other hand, non smoothed voxels are far better for manipulation because they are clearly distinctive.

So what will be choosed in a game could depend on what it's creator want to do.

There is a lot of original things to do, even with unsmoothed voxels. The concept is far less used than vector game concepts or 2D game "revivals" a lot of creator are using.

Quote
Could resolve collisions by using a robust physics library like Bullet,ODE, Newton, etc...

I'm afraid with voxels things are never as simple as gluing pieces of code.

I mean, that could be simple to say and to imagine. But things are never never getting as simple in the reality as  in theory.

Even in cases where making proofs of concepts take only days, resolving side effects could take weeks, making things well polished could take months. And making content working well with this could take years.

Sometimes, things are simple, but I'm afraid it is not the case of this.

Quote
There was another article I was reading on voxel engines in general, about optimizations and cullings... and like for the surface of things, doing combining of continuous areas... so basically the central zone would result in drawing one plane with repeated textures instead of X flat planes of the tops each cube.... which then begins to lose effectiveness on the light blue height-map area with individual arbitrary spires. 

This is an interesting case illustrating the feature exclusion problem we were talking on above posts.

In one word, this method means adding an extra step to connect polygons to make larger ones.

The optimisation will be reducing polygon count and GPU load in exchange of more CPU load before compiling lists.

In Blackvoxel, the GPU polygon count is rarely a problem even on little machines. Execution of display lists are blazing fast.

The problem is the CPU load while refreshing a display list. And this method will increase the problem. And particularly with Blackvoxel because it's increased needs of frequent refresh.

So, this method is well suited for games that won't refresh too often the sectors.

Now, let's modifying some parameters. Let's decrease voxel size by 4 with the same visual limit (so increased number of sectors). The number of polygon will explode and  become a true problem.

That's mean an engine aiming to use little voxels need to use this kind of method.

But that's also mean it will be technically difficult to combine little voxels with MVI even if we don't count the exploding load on MVI itself.

So, that's explain why game choices condition others ones.

Because they are far more resource hungry than vector game engines, voxel engines will remain fragmented for a long time. So a lot of good different games rather than a "perfect one".

Quote
But some things can just be simply boxed with a collision box instead of being voxel-perfect collisions between arbitrarily mixed sized voxel entitites.

That could be acceptable for an entity character. But not for a spacecraft.

The Blackvoxel Team

32
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 27, 2014, 08:24:00 am »
Quote from: d3x0r on October 27, 2014, 03:09:49 am
Quote from: olive on October 26, 2014, 11:54:02 pm
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 from: olive on October 26, 2014, 11:54:02 pm
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....

I understand what you mean.

But Blackvoxel isn't Space Engineer  :)

Every game engine is developed with particular features and choices in mind.

Blackvoxel have it's own features that no other have. And there is a lot of things to dot with these.

True treasures are where nobody is searching, not the shiny things in the other's garden.

The main concern of our team was to make it's own way, to find original concepts and ideas. That's what given it's own personality to Blackvoxel. That's what we'll continue to do.

Believe me, there is more interesting things to do with Blackvoxel actual engine than running after concepts everybody is already exploring. Remember what's happened to all these Minecraft clones.

So, even if we decide for some reasons to switch to multi grid one day, we'll need to do this with an interesting and original way.

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

That's what the engine is doing. But it isn't sufficient at all. That's why there is much more optimizations.

OpenGL/DirectX are mainly optimized for vector games and are big bottlenecks for voxel games.

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

Yes, there is some room left on high end machines. But a game should be playable also on modest machines.

As we ran Blackvoxel on a lot of machines we know that some modest dual cores machines are on the limit with actual load. And there is places where loading is very strong.

Percentage of use given by operating systems aren't really useful about games. Strong stuttering can occur while processors have time left remaining.

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

Yep  :)

The Blackvoxel Team

33
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 27, 2014, 03:06:30 am »
Quote from: d3x0r 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;
}

Yep, that's buggy as hell. In fact, this feature was never tested. Because we found some conceptual problems, we let enabled culling at sector loading.

Quote
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

We are thinking for a long time about adding multi-grid capability. But not decided yet to do it.

Technically, doing multi grid :

Rendering at screen multiple grid is the easy part. Making collision, physics and game interactions is the true big work. This could also lead to rework architecture and change multiple parts.

There is the CPU limit problem : Blackvoxel is already using a lot with MVI. That's already limit for dual cores machines. Unfortunately, Intel is much too slow to popularize 8 cores machines.

For your questions, making it at the world level could be more ideal on the paper. Doing it with sector might be more pragmatic. There is good and bad on two ways.

Some stuff are already implemented to get that kind of thing with sectors :

Sectors are supporting dynamic size along with 'optimized' fixed size.

Some code can manipulate data between sectors.

Look at the "Copy clipboard" and "Paste Clipboard" labels in ZGame_Events.cpp

The Blackvoxel Team

34
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 27, 2014, 01:02:58 am »
Quote from: d3x0r 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) );

...
-------------

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.

That's why avoiding bottleneck in rendering was vital for Blackvoxel. That's wasn't easy to make rendering fluid enough and balance rendering settings for getting fluid and quick.

To alleviate the task of rendering, work had been distributed on other threads. At sector loading/creation, main culling is done. It's completed on the MVI's thread for partial culling. Partial culling is also done on individual voxel refresh.

So you are asking, why partial culling ? Does it is really needed ?

Partial culling is not related to having an entire sector face culled, that's simply because voxels on the sides of a sectors needs to have culling like others. Unless that, it will make visible errors on side... or huge slowdowns if you make sides "all visibles".

The problem is simple : external faces of voxels on side can't be culled without data of the neighboring sectors.

At sector loading and creation, we can't rely on other sectors being in memory, so we made culling for all faces but the outside.

Further, MVI thread check if culling is needed on sectors and look if neighboring sectors are loaded. If so, culling is completed on the relevant side. Making these partial culling make less load on memory system than full culling.

All that stuff is complicated, but it's fast and working well.

So, why wanting to change that ?

In one word : because of MVI. What is optimized in one hand is bad on other.

The system rely on fact the faces are (nearly) always culled. So when MVI needs to move a voxel, it must redo culling on it's faces. Looking at the voxel changing routine will let you understand what we mean : it could be faster without need to keep faces culled.

Since the begining, we optimized rendering a lot with various stuff. It may compensate enough for what will be lost.

It will also be simpler, eliminate a lot of architectural complexity and make it more powerfull for future architectural change we are planing.

The Blackvoxel Team

35
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 26, 2014, 11:54:02 pm »
Quote from: d3x0r 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

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

Yes, it's not always possible to avoid adding overhead when adding features.

Unfortunately, there is actually no way to make all voxel game possible features in one single engine. Some combinations would be technically impossible.

That's why, adding features will always be a matter of choice depending on what feature are wanted for a particular game.

The Blackvoxel Team

36
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 26, 2014, 07:07:02 am »
Quote from: d3x0r on October 26, 2014, 12:45:01 am
...
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.

Hi,

Maybe something could help you  :)

We just published on github some changes allowing to modify voxel size.

But we have taken a particular way to do it.

That's possible because in Blackvoxel, the voxel size is considered to be some kind of base unit.

The player coordinates are considered subdivision of the base voxel unit, something like centimetres. 256 was chosen because it's a power of two.

So, even if the voxel size are changing, the conversion between "voxel units" and "player units" can stay the same.

Look at this line ( in ZActor_Player.cpp), where is defined observer eye position relative to the voxel size.

EyesPosition.y = 256.0 * 1.75;

We changed it to :

EyesPosition.y = 256.0 * 1.75 / COMPILEOPTION_VOXELSIZEFACTOR;

There's also some other locations where some values had to be changed, we did it for selector distance. This remain to be done for player speed.

Of course, player collision should be fixed also with this. But it's "working" enough for testing.

You can change voxel size in ACompileSettings.h with the parameter COMPILEOPTION_VOXELSIZEFACTOR

Changing it from 1.0 to 0.5 will make the voxels smaller.

We hope this could help.

The Blackvoxel Team

37
Programming with Blackvoxel / Re: How hard could smoothing be?
« on: October 25, 2014, 11:08:10 pm »
Quote from: d3x0r 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....

Amazing mod...  :)

Nice marching cube smoothing.

It looks very good in the video.

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

The Blackvoxel Team

38
Suggestions / Re: 3D terrain
« on: October 25, 2014, 10:13:24 pm »
Quote from: d3x0r 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...

Hi d3xOr,

Nothing stop it, all sectors are generated, event those in the air.

Blackvoxel is a "Single Grid" paradigm voxel game, so the voxel space is intended to be continuous and uninterrupted.

Terrain generator selection is mapped in a 2D grid horizontal grid plane, so the generator of a zone is responsible for generating all sectors of the entire vertical "column" of sectors. So that's the responsibility of the generators to generate some kind of filled terrain in the ground and air above terrain line.

Above 64 sectors(4096 Voxels), the normal generators are disabled and a "dust field" generator is enabled. That's what you see in the first seconds of the Blackvoxel video. But you shouldn't see this unless getting really, really high.

Never encountered terrain in the air in the actual version (apart in the floating island zone where it's intended). So, maybe you could have something messed.

Quote from: d3x0r on October 25, 2014, 02:13:58 pm
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....


While generating sectors, the generators can't know what is in the neighbouring sectors because most are not yet generated. So, the generators are typically using the absolute voxel position (computed from sector position and voxel position in the sector) to decide what should be done in a particular voxel.

In the case of your idea of mapping geographic terrain map data, the X and Z voxel coordinates should be used directly to scan the geographic terrain map and return the height at this location. Then a simple test with the Y of the voxel will tell you if the voxel is below or above the terrain line.  All voxels below the terrain height should be render "filled" and those above "empty".
These coordinates can also be used for mapping any kind of formula in the space.

If the sector boundary make some visible fracture, that could be some problem in the computation of the absolute voxel position. Could be a very little problem like an single inverted sign somewhere.

The ZWorldGenesis::GenerateZone_BlackWoods() is a good example of a terrain generation following an heightmap given by an interpolation formula. This function is generating the black terrain in the giant three zone.

The Blackvoxel Team

39
Suggestions / Re: 3D terrain
« on: October 24, 2014, 11:45:49 pm »
Quote from: d3x0r 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...

It's a very interesting idea. :)

We will look at the problem.

The Blackvoxel Team

40
Programming with Blackvoxel / Re: Voxel pixel selector box, render offset
« on: October 24, 2014, 12:01:35 am »
Quote from: d3x0r on October 23, 2014, 04:40:54 am
Right; I actually ended up replacing '256.0' so it missed all the integer versions... there are a few other places that 256 is used...

I ended up making a separate global varible "VoxelSizeInBits" which then expands and creates the actual voxel size... then I had the number to fixup the shifts too.

'12' and '16' are also rarely used numbers, these were shifts from world space to sector (world_bits + ZVOXELBLOCSHIFT_[x/y/z]) and a few places where it was just '8' from world space to voxel coordinate.

most compiles generate shifts if the constant is a power of 2 in a multiply or divide when generating optimizations; at least MSVC and GCC do.

-64 = 0x(ffffff)C0
dividing or shifting a signed variable results in the same value
if the value was an unsigned integer the shift would give the wrong result because it would not be sign extended, and would be 0 filled at the top instead...

Yes, compilers are replacing some divide by shift. But there is a trap...  ;)

Look at this program:

Code: [Select]
    int a = -64, b, c;
    b = a / 256;
    c = a >> 8;
    printf("Divide : %d\nShift : %d \n",b,c);

This will give you the following result:

Code: [Select]
Divide : 0
Shift : -1

(Note it uses only signed integers.)

So, the program give us different results with divide and shift. And we use the "right" signed arithmetic.

Lets analyse how shifts are working:

This is how -64 is coded in binary:

1111111111111111111111111111111111111111111111111111111111000000 = -64

Naturally, we must use the appropriate x86 signed right shift instruction (sar) to preserve sign in the shift.

So, shifting by 8 with preserved sign will give you:

1111111111111111111111111111111111111111111111111111111111111111 = -1

Right shifting this negative value will never give 0 even if shifted forever.

So, shifting, even with signed instructions don't give the same result for negative numbers than division.

You said compilers are optimising some divisions with shift: yes it's entirely true. But there is some subtlety in what they do.

Looking at the assembly code comparing how shift and divide are translated to assembly(with GCC), we found:

c = a >> 8;
Code: [Select]
mov -0xc(%rbp),%eax
sar $0x8,%eax
mov %eax,-0x4(%rbp)

No surprise, pure shift is translating to "sar" x86 instruction.

And for the divide form:

b = a / 256
Code: [Select]
mov -0xc(%rbp),%eax
lea 0xff(%rax),%edx
test %eax,%eax
cmovs %edx,%eax
sar $0x8,%eax
mov %eax,-0x8(%rbp)

That's where things become interesting.

The divide instruction is translated to shift instruction... but other instructions where added by the compiler.

In few words, these instructions are testing if the value is negative and in this case, the input value is adjusted before being shifted.

This clever trick give the right result for negative value shift.

But without this fix, "shift as divide" would have given an incorrect result for negative numbers.

The Blackvoxel Team

41
Programming with Blackvoxel / Re: Voxel pixel selector box, render offset
« on: October 23, 2014, 01:38:20 am »
Quote from: d3x0r on October 21, 2014, 05:29:08 am
...
I reread some of the things on your board, and I realize you're not looking for code input you're looking for funding input... so I'm gonna stuff a copy in my own repository so I can at least track all these changes...

Thanks for sharing your code.

Yes, as a free software project, we need to find some funding, but we are also searching for contributors on the game itself. That's one of our main priority.

To help to contribute we have published the Blackvoxel source code on GitHub here: https://github.com/Blackvoxel/Blackvoxel. See the announcement here http://forum.blackvoxel.com/index.php?topic=67.0 and here http://www.blackvoxel.com/view.php?node=1550. So you would be welcome among contributors  :).

The GPL licence is the only fixed rule: as a free software basis, programmers should remain free to do what they want or contribute to what they want to.

Contributors can choose helping us to improve or develop some point we'll discuss or items on the roadmap as they want to.

Or (at their choice) they can develop their own ideas on a "fork" basis without constraints. We can decide at some point (on our appreciation) to bring some ideas and/or code we found interesting to the main project.

Organising contributions is not an easy job as we may have to make decisions about project direction. But with time, we'll certainly find how to make best for it.

One last thing : when we'll integrate some code or ideas, we'll add the contributor names in the game credits screen (and appropriate credits citation files). So don't forget to put your real name somewhere if you want it to be listed.

The Blackvoxel Team

42
Programming with Blackvoxel / Re: Voxel pixel selector box, render offset
« on: October 22, 2014, 11:34:16 pm »
Quote from: d3x0r on October 21, 2014, 03:28:56 pm
Fixed that; I ended up missing searching headers for '256' and '128' (and shifts....) but most important there was a translation of player position to player sector position that was not updating correctly... so every sector block was outside of distance and qualified for ejection.

much more stable now... (well as stable as before I started mangling it with a global setting for block size)
really want to make it more like an object setting ala Space Engineers

Hi d3x0r,

If you changed code for conversion, there is a little trap in the player to voxel coordinate conversion. If you replace shift by division it won't work because result is different on some values. Try with negative value -64.0, division(/256.0) and shift(>>8) won't give the same results. That could be enough to mess a lot of things.
The shift conversion was used to avoid having two "0" voxels ( 64.0 and -64.0 position would have given the same result : 0).

Another problem if you replaced the "256" constant in code is that this number is also the number of voxels in a zone. The zone is the unit for the generator to choose the kind of landscape that will be generated. That's used in some code in the generator ("ZWorldGenesis.h" and .cpp).

The Blackvoxel Team

43
Programming with Blackvoxel / Re: Thoughts on large body collisions?
« on: October 22, 2014, 10:36:37 pm »
I see you have looked at the collision stuff  :).

As you can see, the system use a collision points matrix and is raycasting on them with the displacement direction to detect collision on the path of these collision points. The system is optimized by enabling and disabling some points to enable different "detection planes" depending on the displacement direction.

So, you have understood that with smaller voxels, the "holes" in the grid are too large.

One solution could have adding points on the "collision grid" to fill the gaps.

But the problem with a 8 voxel height character is the number of points that will lead to some problems :

- The actual code need some redesign to organize such number of points.
- Some optimization problems could arise with big number of calls for individual raycasting points. But it should be tested.

So, changing the approach could be a good idea.

But maybe you could use some kind of "collision volumes" around the player.

Iterate through these volumes and find the nearest collision voxel if any.

Remember you need the collision distance to allow the player to travel until effective collision.

The Blackvoxel Team

44
Programming with Blackvoxel / Re: What things are already available?
« on: October 18, 2014, 04:26:54 am »
Quote from: d3x0r on October 18, 2014, 01:12:48 am
Do you have something like 'the voxel in-line with the screen pos at a certain distance' sort of thing?  I found the add a block on right click, and extended it to do something silly like make a cluster of blocks in a relative direction... So it's pretty easy to set voxels in the world.

Is there something about the order to set voxels in so transparent textures work better?  When I used fiber optic, repeated, complex stepping had transparency issues, that the textures further back were rendered over the visible fronts...

Something like in space engineers, when you create a new ship, your first focus is at a fixed distance from you along the mouse ray.
-----
THe other feature I was thinking I'd like would be, the block next to an existing type of block that the mouse ray is passing through... I realize that if you were looking down a wall that many voxels in line would be valid... so again maybe at a distance from the cursor... use like ctrl or alt-scroll wheel to set the distance?  Maybe I don't want that... maybe I can just click on a point to begin pathing.... well see still need to know which side near that block the mouseray is going through...

Like if I start with a center block in space (give the player a zero-g jetpack something) was going to use a center block with 6 blocks around it also filled in as a base shape for a neuron, and use the 6 voxels around it as connecting points... then still in that place, to extend a line outwards from there; in space engineers creative you cyou can hold ctrl and when building it selects a line of blocks... it's only a valid line when the mouse ray passes through a block on that line... so in theory there's 6 lines that extend out from this central shape, that I want to extend out away from myself, so i can't see the face to add the block to...

If we understand well, what you are looking for is the voxel "pointing" system. That's the ZVoxelWorld::RayCast_Vector() function. Give it a point on the space, a direction vector and it will tell you the next "pointable" voxel in the line.
The game itself use it in ZRender_Basic.cpp at line 517. Parameters are initialized in lines above.
The algorithm use a kind of ray casting algorithm. We don't know if the parameters are explicit enough. Tell us if you need some info.

About transparency problems with some elements, there isn't a simple and definitive solution... but there is some possible workarounds to avoid them. In one word, the order in which voxels are set doesn't matter.

Let's explaining :

In Blackvoxel rendering, the polygons aren't sorted by distance before rendering. That would have been way too slow to do this on Blackvoxel because this game need VERY heavy rendering refresh activity.
So, we choose what we think is the best compromise on this particular game and it's particular needs... but the method isn't perfect.

Other games with different paradigms and goals can have made different technical choice to fit their particular needs. Blackvoxel rendering engine is strongly tied by the exigence of very fast refresh and rendering with an huge voxel grid universe. And so we had to do some technical choices for speed.

But we also implemented algorithms to mitigate these problems the much we can without costing too much machine power : Sectors rendering is sorted by distance and transparent voxels are rendered on a separate pass after "non transparent" rendering. There is also an alternate rendering path for some zones.

The problem remains between transparent voxels themselves.

That's where there is some requirement to design transparent texture that made them "blend well" despite unsorted rendering.
  • Semi transparent textures should be uniform (like transparent glass).
  • Different level of semi transparency should not be used on the same voxel (but you could use full opaque and transparent at the same time).
  • No semi transparent and opaque on the same voxel
  • Textures with transparent zones and opaque zones (like leaves) must have no zone with semi transparency
So, it look like we have to redesign the optical fiber texture.  :o

About the voxel selection algorithm, it was designed for the actual game. But you could change it for doing what you need. The raycasting algorithm we talk above can tell you what side of the voxel is pointed and some other useful informations. And you can also implement some kind of "space pointing" not tied on the fact one voxel is existing, simply by pointing a voxel at some distance. The ZRender_Basic::Render_VoxelSelector() function can also help you as it's the rendering of the "selection lines".

The Blackvoxel Team

45
General Discussion / Re: What I want to do....
« on: October 16, 2014, 08:57:33 pm »
As we understand, you are thinking about some neural network stuff.  :)

That's a good idea because the Blackvoxel's Molecular Voxel Interaction Engine is a kind of neural network engine in itself and can be well suited for that kind of use.

No carbon remain on the Melting Furnace after melted material get out (quantity is reset after output in ZVoxelReactor.cpp at line 1714) but there's a phenomenon that can make you feel it like this : molten materials are exchanging their content by contact after getting out.

So if you put too much carbon for one element and the right quantity for another, if the blocks are touching after getting out, an excessive amount of carbon can contaminate other molten blocks. The molten blocks are mixing like you can expect of a liquid material in real life.

The Blackvoxel Team

Pages: 1 2 [3] 4 5 ... 10