Blackbox Voxel Tool

[RAV]

First public release experimental demo of Blackbox Voxel Tool. Download here (latest version 020c). Post and discuss art in this thread.


Update April 28 2016:

A lot has happened since my last activity here. Although much remains yet to be done.
Several updates have fixed and upgraded Blackbox into a different nature of creativity.
I would hope you have familiarized yourself enough with the first basics of the principle.
The new mechanics invite much experimentation and exploration of a depth unique to this tool.


These videos give a little hint:









Old introduction to topic:


The hotkey system discussed in the accompanied readme.txt may be a bit much at first, but will make more sense eventually.

This release omits the tiling capabilities shown in the videos previously, as well as the animation discussed on my website.
That will come with the following releases, alongside a better GUI. But it also sports abilities not shown or discussed yet. So do read the readme.

Still, there are a great many more or less obvious features missing that keep this from being an actual tool more than a toy. I consider this tool like the body of a living creature. It has vital organs, a heart, lungs, brain, any of which must be there and work properly, or the body can't live. There is a systemic dependency of functionality, so that the creature can go about the way it's supposed to. But this release right now would cut down from many vital functionality that define its true nature, its workflow, its very usefulness. For example, a selection snapped to grid is just a strange quirk only by itself. It is the crazy possibilities of the new tiling here that decide its usefulness, and entirely change your workflow. But that is not in this release. All you're stuck with is this weird selection then. And there are many other missing features just as important in defining the real identity of this tool.

The purpose of this release is to concentrate on studying the reactive behaviour of the grid, the visual behaviour of coloured cubes by side, the use of perspective on very large scale, and the basic idea behind the control scheme. Try to work around the tight cube limit with what you got, see what kind of visuals you can do with that for a mockup scene. That's enough for now. It will give you a first base of understanding. On the following releases it will start to actually get interesting then going from that.

As you play with it you may eventually notice problems innate to this medium.
Some of it will be solved, some will solve themselves as computers improve, some you may always have to work around.
We are here to study the potential, viability and proper use cases, alongside the limits, of this proposed technique here.

Also a couple more immediate issues remain that will be addressed in the future. Among them:

This project focuses on the very experience of the pixel art medium's process. It attempts to have a natural approach to it. One of its key features is a resilient and efficient Input Interpolation that enables beautiful line drawing, mostly uninterrupted even across corners and complex environment. However this needs more tweaking. For example, aggressive as it is now, it can happen that it paints a hidden side on edge cases, which prevents a reoptimization of the grid upon large overpainting. When you see it, use shift-paint to recolour the location wholesome, so the grid recovers.

Deleting a voxel can sometimes be a bit jumpy on the edge.


Have fun and work hard.

[RAV]

Download new version hotfix 0.1b


Updated readme.txt with corrections and additions. You should give it another look.


Fixed massive performance issue when deleting voxels with the left mouse button instead default right, and also when painting on surface of same colour.
Fixed other various issues tied to not using default controls. Reconfiguring controls broke input interpolation overall. Not anymore.

Fixed Line tool behaviour of Paint mode. Working as intended now.

Some other minor fixes.


New features:

You can toggle on/off the default smart select for a rougher method with key g.
While the finer smart select is more useful most often, sometimes it's really nice to select more sweepingly.


Improved palette management: colours can be moved as whole blocks at once by holding ctrl key while using arrow keys.

Pressing Backspace deactivates/activates the currently selected slot.
While holding ctrl deactivates an entire block of active colours beneath.

Arrow keys up or down to move in colour palette.
while holding shift moves a colour up or down the palette, by swapping the colours of slots.
while holding ctrl moves an entire block of active colours above or beneath up or down the palette;
when block connects with another block in palette, they become one and move together.
while holding ctrl + shift moves an entire block of active colours above or beneath up or down the palette;
when block connects with another block in palette, it passes through it, colour by colour, trading places.

Arrow key left or right changes palette entirely.
While holding shift copies the current slot colour to the same slot of next palette while switching.
While holding ctrl copies the whole block of active slot colours beneath to the same slots of next palette while switching.
While holding ctrl + shift copies all the colours of palette to the next palette while switching.

It's probably most useful in general to organize your palette in separate blocks of active colour.

The first and last slot of a palette are the system colour slots.
They can't be moved or manipulated. But they don't count towards the max colours of a palette.



But further improvements coming.

[Gil]

If you could find someone to do a basic video tutorial, that would be very very much appreciated. Going through the program with the readme next to me causes information overload. I'd really love to try this out, but the learning gap seems a bit steep for me.

[RAV]

That is understandable. Thanks for your interest. Currently I'm still concentrated working much on the fundaments than that making tutorials would be a good investment of someone's time. This is far away from what it's supposed to be. It is more spontaneous "nightly" releases. Next hotfix update coming soon fixing the last. The many quick changes will make videos confusing soon. And the current hotkey driven state of affairs makes video showcases not much more informative. The releases here are still what I consider "should never have been". After some circumstances in my life changed, it is an attempt of opening up my development for a certain kind of people really interested in experiencing hands-on that sort of rough and dirty behind-the-scenes look on the progression, and provide experimental means for further research on the meaning of what is pixel art in this era. We are going very text intensive, very conceptual, very power user oriented here, for the time being. I do believe for the very basics of toying the tool, it is simple enough and enjoyable even as of now though. Beyond that, the hotkey controls, while reading overwhelming at first, make systemic sense soon.

[RAV]

Download Hotfix version 0.1c


Fixed moving colour block behaviour in palette, especially on transfers between palettes.
Working as intended now. Remember, first and last colour of palette are unmodifiable system colours now. (not entirely: you can still shift-pick it, but that's fixed next version too)

Changed colour palette quick scrolling from shift to ctrl + mousewheel.
Because using shift/capslock for alternate controls on tool functions,
made the also corresponding size/palette switch on mousewheel annoying.

Before that, the activated Line tool didn't let you do size changes anyway, to keep its integrity.
So having ctrl also switch mouswheel from size change to palette scroll is a nice fit after all.

hope you didn't get too used to it yet, that's annoying too.


more coming.

[Ai]

Good to see you released some version of this..
FWIW, doesn't work in Wine. Wasn't really expecting it to, but looks like a GLX error:

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  154 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  171
  Current serial number in output stream:  172

Might be fixable with Wine knowledge beyond what I have (probably whatever it takes to get the average 3d game running would deal with it).

If anybody wants to make a visual cheatsheet for the shortcuts, http://keyboard-layout-editor.com/ makes it pretty easy to do that and get a PNG/SVG/etc out.

[RAV]

Hello AI. Thanks for the notice. And that cheatsheet thing is a good idea.

I am currently developing this through Wine on a crappy netbook running Ubuntu, because my main rig got trashed.

It runs very well there. Actually, in my tests it currently runs much better on Ubuntu than Win7. except for resizing window being very choppy.

[RAV]

Download hotfix version 0.1d


Fixed last version's massive performance issue on shift-Delete Shoothrough.

Fixed ctrl + backspace colour block deactivation from first colour of palette

Some other minor fixes.



New feature:

Press key Enter to Mark current colour in the palette.
while ctrl, marks entire block of active colours beneath.

More specifically, key Enter toggles the mark,
and ctrl + enter toggles mark for entire block;
unmarked colours become marked,
marked colours become unmarked.

The mark is remembered when moving colours
and on transfer between different palettes.

When using ctrl with the RGB colour component modifier keys,
the change now affects only all the marked colours in the palette.

This allows more effective colour palette management.



More coming.

[RAV]

uh... some weird shit happened on compile..

ctrl + enter and ctrl + backspace do not seem to work on this version..

fixed next.

[RAV]

uuuh. getting weird. Talking about linux wine and windows differences...

This last version's ctrl-backspace and ctrl-enter seems to work fine in win7 but not in ubuntu wine now.

no explanation for this right now. one of these WTF moments once in a while.

Or is it just me? my piece of shit computer degrading?

wouldn't be the first time it acts up bogus to make me hunt non-existent bugs for hours. :-/

[RAV]

Download Hotfix version 0.1e

This version has none of these issues for me on Ubuntu Wine anymore.

Also some other minor fixes.


I know a bunch of you are into Linux, so even though I don't offer native versions right now, I did what I could to have it run there fairly well.


Sorry about the spam, but it's hot on the heels of the release, and I want the situation cleared asap.

I think though that it got to a point nothing's critical. I'll do bigger and less frequent updates now.

[RAV]

Naw, we keep going a while longer for the holidays. =p

Download hotfix version 0.1f


Done some minor fixes.



New features:

Mini cams can swap places now.
Keep holding any of F1 to F4,
then press another cam of F1 to F4.

Press key b to set your main view back to its default status.
while holding shift sets the currently selected mini cam back to its default status.
while holding ctrl sets all mini cams back to their default status.



Changed control:

For quick scrolling the palette, both key combinations work: ctrl + mousewheel and shift + mousewheel.

While capslock still is a permanent shift +, it does not affect mousewheel for palette scroll.
You still need to press shift for palette scroll while in capslock.

Explaining this might sound confusing at first, but in practical use I found this the most sensible and convenient.

[RAV]

Download hotfix version 0.1g



Fixed Capslock behaviour with rest of the controls.

Capslock permanently activates the alternate functionality of only the mouse buttons, like holding Shift would.
But Capslock no longer interferes with any other hotkey like holding Shift would.



Changed control:

You can use Swap mini cams now without changing your mainview,
As long as you hold a F1 - F4 key, the main cam does not immediately jump, but select the new mini cam.
Only when you release the key does it actually jump to the newly selected mini cam.

This allows for swapping cams without jump of main view,
because when you press another F cam key while holding the first,
it will know to swap cams but not jump main view upon releasing keys.

But this scheme also allows other operations on mini cams.

While holding any of F1 to F4 for selecting mini cam,
and then pressing key b, sets that mini cam back to default status,
without a need to jump mainview to it for selection either.

[RAV]

Download hotfix version 0.1h


Added changelog.txt to distribution.


You can toggle on/off grid view of any mini cam
by the same method discussed above.
Keep holding any of F1 to F4,
and press the Tab key.
won't switch main view.


Colour control for Hue, Saturation, Luminance.

The keys used for RGB modification are now by default HSL controls.
If you still want RGB control, hold Shift while using them.

As before, the HSL controls can be used on several colours at once,
by first Marking them, and then holding ctrl while using modifier keys.
Again, shift + ctrl now for RGB modification on several colours, as before.

Remember:

Press key Enter to Mark current colour in the palette.
while ctrl, marks entire block of active colours beneath.

More specifically, key Enter toggles the mark,
and ctrl + enter toggles mark for entire block;
unmarked colours become marked,
marked colours become unmarked.

The mark is remembered when moving colours
and on transfer between different palettes.

When using ctrl with the RGB colour component modifier keys,
the change now affects only all the marked colours in the palette.

This allows more effective colour palette management.

And also remember:
-- colours are indexed.
-- the scene updates realtime as you change colours.
-- the palette colours keep integrity while on mass modification, allowing to play with extreme effects (HDR).
-- but first and last colour in palette are system fixed and not modifiable.

[RAV]

Download hotfix version 0.1i


Page-wise colour palette quick scrolling with ctrl + mousewheel.

Slowed down colour modifier bar speed, framerate independent.

Toned down RGB colour bar indicators, so they are not visually distracting.

Moving around colours in palette no longer messes up a finished scene, as colours no longer "move out of their slot" to which the cubes would still be tied. That means you can at any point of your work arbitrarily reorganize your palette without messing things up. This is a very significant fix.

Some other minor fixes.

[RAV]

The Problems of Blackbox



So far I have been mostly discussing interesting abilities and advantages of Blackbox. They are its reason for existence, after all. And the possibilities are exciting.

However, it is just as important to discuss the problems that come with that. For all its promise, Blackbox is not short of problems either. And to use this tool to its best, we need a good understanding of them, in general and in detail. We will discuss how we can make Blackbox work regardless. Hopefully this can also give some interesting insight into problems of art at large. We will start out with a first Article of this series.




Image Quality


You should have noticed soon in your tests that image quality may be the single biggest concern in working Blackbox. The issues of image quality are a form of restriction to your art. You have this amazing power in scale, but it takes much careful design to make it work well on the eye.

In the beginnings of 3d graphics, image quality was not the primary concern. It was making the illusion of reality work to begin with. And in a sort of greed, drunk with possibility, the art of these titles aimed for more than is aesthetically sane. And the audience of the time, amazed by this new age, was able to ignore the visual problems in a suspension of disbelief. But ever since times have changed. 3d is ubiquitous, and the expectations and standards have been drastically raised.

Image quality has become one of the most important measures. Many new technologies have been invented to improve it. All of graphics and display products contest in it and advertise its importance. And our eyes have been incredibly spoiled by it. Look an old CRT today, watch VHS video cassette, play Doom in its most original rendering code, and you will find all that extremely difficult on the eyes, it almost literally hurts. So it didn't take long before 3d entirely abandoned pixel art in favour of much filtering. Strict Pixel Art has the smallest margin of mistakes in readability, and a dynamic view breaks that very quickly. The goal was not to find an art that makes 3d work as is, but to find a tech that makes realism in 3d work.


In its raw approach to the artistic rendering, Blackbox faces many of the same challenges the first 3d games had. But the difference we have today is, we better understand the art to deal with it. Pixel art itself as an art form and theory, transitioned to a more image quality oriented approach in the meantime. In 2d, it is the utmost polished impression of pixel art that set it apart from competing art forms. And drawing from a better understanding of pixel art today, we reinvestigate the raw rendering in the 3d of the past. We focus on studying the range of values in which it works by smart design of the content. And we attempt to turn its crisp visuals from a liability into a proud and pleasing quality within these bounds.

Appropriate art techniques aside, the level design, view ranges and perspectives in relation to cube sizes, are also of great interest to us in working around that. Isometric worlds may be the most straightforward to look good, but a clever room and vista layout too can set the bounds for good image quality even in First Person View. Also consider on the technical side, that advanced system work such as an intrinsic level of detail system can also improve upon the situation across the board.



However, do take note: new display technologies, like ultra HD displays, which will become market standard in just a few years, will ease our problems and expand the ranges and use cases. Even our normal HD displays today give us a huge leg up compared to what people of the past had to deal with. Altogether, raw rendering is a much more feasible approach than it has been. But make no mistake, image quality will always stay the maybe biggest concern of Blackbox compared to other tools.

Another thing to consider is, that we can try further ease it up with fullscreen anti-aliasing on top of that. Though this might sound heretical at first, it would be simply an equivalent to the quirks of older display tech like CRT. But this has the lowest priority of interest to this project. To learn most in our study here, we make our case tougher by dealing as is, and will later benefit ever so more from a better understanding in improved conditions, may things come as they do. Laziness is learned quick, discipline must be achieved.

[RAV]

Download hotfix version 0.1j

Render System Upgrade: Stage 2. Improved runtime performance and memory footprint.

Maximum number of cubes tripled, from 100k to 300k.

Fixed occasionally vanishing scene.

Fixed Shift and Ctrl not working on mini cam after mini cam key is already on hold down select.

Mini cam default size adjusts to screen size on bootup.

Capslock no longer affects the Pick colour tool. That was too annoying in most use cases.
Always hold Shift if you want to assign a cube's colour to a slot. Tip: you can use this to copy slot colours.

Some Operating System versions seem to intercept the key combinations Ctrl + Enter and Ctrl + Backspace.
If these don't work for you, there are now alternative keys: Use the punctuation keys,
Comma for Backspace, Period for Enter, and each in combination with Ctrl.

[RAV]

Download hotfix version 0.1k


Further optimizations and improvements to the rendering.

Increased cube limit from 300k to 600k.

Fixed an issue with windowing on smaller screens.

Fixed an issue with auto-resize on mini cams.

Reduced render faults on mini-cams; some machines had it especially bad.

[RAV]

>>> BVT_v01l -- March 6, 2016 <<<


Increased cube limit from 600k to 900k

Fixed Line tool (holding Ctrl key).
While the Line tool worked fine on Ubuntu Wine,
for actual Windows users it disappeared after
about one second upon still holding the Ctrl key.
The Line tool now stays active as long as you hold the Ctrl key.

Fixed block colour palette Marking (Ctrl+Enter)and Deactivation(Ctrl+Backspace) for Win10 users.



Added Copy&Paste, for a first take on tiling.
This transforms the workflow of Blackbox into Pattern Orientation.

Whenever you have selected more than one cube,
the Pick tool marks that for Copy&Paste, instead of colour.
Remember, you Pick either by pressing key "r",
or by default Right Click Mouse in Paint Mode (key "2").


Note:

Be sure to give this new feature a lot of attention.
Experiment with patterns of beauty, construct fractals.
This feature is very powerful, remember the second half of
the Natural Selection video for some examples on usage.

Always look out for picking reusable patterns in micro or macro,
similar to how you would pick colour.

As you should expect, you can easily resize the copy upon paste
simply by changing selection size with mousewheel.
There are various uses for that:
-- prepare your tileset at a comfortable work size,
and then miniaturize it upon actual use,
to fully leverage world scale.
-- hide your tileset as "micro film" within world.
-- fractal construct mass and shape very quickly.
etc.

This current copy is a straight location copy, instead of instanced.
That's probably going to change later, but in the meantime this enables
some interesting fractal tricks, like "infinite mirror"-esque effects.
It happens when you try to paste within the area you picked for copy.

Hard copy is very expensive, both in processing and memory usage.
This will be circumvented when referenced soft copy from tile palette comes later.

When a tile has holes through which you can see other tiles behind,
this may be problematic to paint with, since it may shoot-through.
Until this is fixed, remember that you have alternate Selection modes.
Use key "g" to toggle default Smart Select. Turning it off can avoid the problem.

Rotation and flipping still missing. Comes later.





>>> BVT_v01m -- March 7, 2016 <<<

Non-public dummy version.





>>> BVT_v01n -- March 8, 2016 <<<

Improved performance of operations on model for mass modification.
(Deleting or copying large numbers of cubes should be noticably faster)

Fixed crash in extremely complex scenes.
(too many unique vertices tracked; connected
cubes/triangles in Blackbox can share their vertices,
for reduced memory and coherent mesh deformation.)





>>> BVT_v01o -- March 30, 2016 <<<


Fixed performance breakdown after picking a Tile with large amount of cubes.

Fixed recurring issue with the new Pick while in capslock.

Fixed crash on close.


Reduced aggressiveness of Input Interpolation upon drawing.


Added marker graphic on picked tile.

whenever your current selection leaves
the area you Picked, a marker shows
the location you will copy&paste.


Added Rotation.

Copy&Paste now auto-rotates tile.

This depends on:
The side you were picking the tile at,
and the side you are pasting to.

This is useful for both,
intuitively painting tiles on different walls,
and rotating a tile on the same spot.


Holding key Shift while Picking a tile,
deactivates auto-rotation for that tile upon paste.
The sides of picking and pasting then don't matter.


This feature plays to an advantage in workflow of 3d.
You can reduce the minimum amount of tiles required for a full set,
and greatly enhance visual variety at little to no extra work.
Further takes advantage in fractal mass construction methods.


More manual rotation and flipping come later.





>>> BVT_v01p -- April 1, 2016 <<<

Fixed crash when trying to copy&paste in some odd situations.

Fixed various problems when changing side of same selection.

Adjusted behaviour of the visual Marker for tiles.


Added manual rotation and Flipping:

When holding key Alt, the movement keys w, a, s, d, q, e
flip and rotate the currently selected side of cube or tile.

ALT + q, e: counter-clockwise and clockwise side rotation.
ALT + w, a, s, d: Flipping of side, up, left, down, right.

Use this to further adjust the normal auto-rotation of pasting.





>>> BVT_v01q -- April 22, 2016 <<<

Fixed all keys for all platforms, a possible crash and some minor issues.

Blackbox should perform the same on all platforms now.

Increased max number of cubes from 900k to 950k.

Decreased minimum movement speed,
alongside other adjustments to cam,
slightly more convenient for details.





>>> BVT_v01r -- April 24, 2016 <<<

Fixed an issue in which mouse buttons in free mouse mode
would only execute function when holding button and moving mouse.

Added improved line tool preview,
with actual wireframe cubes lined instead of just a simple line;
only reverts back to simple line if line is very long with too many cubes.

Increased max number of cubes from 950 thousand to 2 million.





>>> BVT_v01s -- April 28, 2016 <<<

Fixed total performance breakdown on colour changes in massive scenes.
Scene updates after you're done changing colours with slider movement.

Increased max number of cubes from 2 million to 2.4 million.

Note: Blackbox is currently on greedy settings for tests.
Gaming-grade machine required, with recent drivers,
and no other expensive programs running for resources.
If these conditions are not met, you see no starting cube.
Restarting Blackbox or your computer may help clear it out,
otherwise upgrade your graphics card, with 2gb vram recommended.

[RAV]

See accumulated changelog above.

A lot has happened since my last activity here. Although much remains yet to be done.
Several updates have fixed and upgraded Blackbox into a different nature of creativity.
I would hope you have familiarized yourself enough with the first basics of the principle.
The new mechanics invite much experimentation and exploration of a depth unique to this tool.

Download Blackbox v01s and find out yourself.

These videos give a little hint:

[wzl]

This is shaping up to be a really cool toolset. I like where you take it in terms of scalability and functionality! 

I was thinking about a voxel world builder for some time. mostly in terms of usability and problems its supposed to solve.
Problems like fast and efficient world building for example.
What i'd personally like to see is a sort of voxel template library, sort of like a tileset, but probably more for arbitrary sized objects.
i.e. you build some geometry > select it > save to templates > maybe name it or save to a named library (walls, floors, what have you) > use tab(or else) to pick a template and place it down. This would work for both grid based world (similar to pixel tilesets) as well as non grid-bound(or not snapped to grid) stuff (random trees and rocks dont need to align to a grid but can be freely moved and assembled wherever).
For architecture building i'd like to see features like select>drag faces.
i.e. you select a cube>hover one of its faces>click and drag to copy it along the dragged path. This should also work for multiple selected cubes.

I'll give your tool another spin when i have some time   
good stuff man

[RAV]

Thanks wzl, looking forward to what you can share.

Yeah, that kinda stuff is on the list. It's scary how much there is still to do, even though I've done so much. And everything becomes quite tricky at this scale and various resolutions. But a first take on multi-selection of cubes and colours is probably in one of the next updates.

What I like about this current version is its conceptual clarity, though. It has an almost aesthetic quality on the technical level. Everything from here on out is basically just a convolution. I'll be very careful about my steps, because the greatest priority of this project is nailing in on a specific kind of creative experience, and I need the basics of that to be spot on first.

Glad you could run it. I prolly over-did it on this version. It's kinda a shame, because it's actually much more flexible than that. The settings will likely open up some other version. I wanted to see some burning wheels on the tech, and a first sense of epicness on the scene already, before referenced tile copy comes in. What we have here right now, is a pool of 2.4 million cubes for unique material, tiles, sprites, what have you, on a sheet, for endless copy to screen, just like the mini-cams do. As it stands, in the worst case scenario, those cubes translate up to 28.8 million triangles, and all rendered up to 5 times on the screen. So altogether, we got a lot of through-put to manage, and I think it handles that well. My own computer is low budget, and it does fine.

Anyway, right now, for the lack of save, playing with it is certainly an exercise in futility, like the Tibetan monks do with their rice art. I'm just happy it got to a point it's not all fundamentally broken, and can serve as a prove of concept for study. I definitely would like to see some art tests though. And for that I would recommend precisely to be lazy, trying to make the mechanic work for you, to learn it inside out, especially with abstract art. So the challenge would be akin to speed art. What can you do in 15 minutes? And then I think, some simple revisionary Zelda- or Castlevania-like mockups should be doable. I would expect Pixelation is able to beat other such efforts in quality.

[RAV]

Download update version 0.1t

Upgraded window system: stage 2.
Virtualized windowing on gpu,
for better resource management
by cascaded Framebuffer system,
through rendering to texture.


Fixed screen tearing when moving through busy scenes.

Fixed occasional wild jumping window when moving it.

Fixed key c reacting only to release.


Reduced greatly the runtime cost of the mini cameras.
You can easily use them all even in complex scenes.
Takes less battery on Laptops, from idle to run.

Improved overall smoothness of operations
and behaviour in video capture.


Added controls for transparent graphical user interface.
alt + F9 to toggle backround of palette menu bar.
alt + F11 to toggle backround of cams menu bar.

Added controls for mass cam modification:
ctrl + tab to toggle grid for all mini cams.
ctrl + shift + tab to include main cam.
ctrl + b to reset all mini cams.
ctrl + shift + b to include main cam.


Added adaptive memory allocation.
Currently available vram is detected,
and max number of cubes set accordingly.
It ranges from 300 thousand to 6 million.

If the last version didn't work for you,
there is a good chance it does now.




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



There are a couple things I couldn't test, so if anyone here can, that would be great.

I need people with a beefy graphics card, with at least 4gb vram, ideally you'd have 8.

For Nvidea users, I need confirmation that you can reach the cube limit without crashing.
Just start plastering cubes until nothing goes, you know how to multiply shit quickly, right.

For AMD/ATI users, I need confirmation that the vram detection works to begin with.
If it doesn't, it will assume the minimum value, which should be noticeably less cubes than the last version.

[RAV]

Download update version 0.1u


Fixed scene not updating correctly on palette swap or shift-pick colour or shift-delete cubes.

Fixed copy marker disappearing on no selection, and changing colour on different selection.

Fixed scene corruption by faulty video ram allocation on high end machines.

Fixed GUI not properly adapting and scaling to various screen resolutions.

Fixed crashes in multiple instances of program and input interpolation.

Fixed selection symbol not updating properly in some situations.

Fixed manual rotation on tile with gaps losing selection focus.

Fixed delete cube sometimes behaving unreliable on edge case.

Fixed unintended shoot-through on paint copy tile with gaps.

Fixed screen tearing and stutter on powerful machines.

Fixed painting not working across sides of same cube.

Fixed failed vram detection on AMD cards in Windows.

Fixed paint copy tile drawing through empty space.

Fixed wrong colour when using uninitialized slots.

Fixed faulty start-up view on some host platforms.

Fixed crash of faulty system ram allocation.

Fixed crash in Line function.

Fixed some internal issues.


Added scroll bar indicator to colour palette list,
for better orientation and management.

Added indicator for detected graphics chip vendor, in lower left corner.
Green square is Nvidea, red for AMD, blue Intel, black undefined.

Added indicator for cube count, next to gfx detect indicator.
Every square in row means 50k cubes available in total from memory.
They flip between a dark and bright shade for better differentiation.
A white line going through them means how many cubes currently in use.

Added manual resizing of palette menu bar.
shift + F9: increase size of palette bar.
ctrl + F9: decrease size of palette bar.


Note:
The maximum number of cubes is 1.5 million now,
depending on available video ram, limited at 2gb max use.
This memory limit remains until the code moves from 32bit to 64bit.

Resolved website downtimes and faulty ssl certificate warnings when using .www,
both caused by server relocation of the webhost service provider.

[RAV]

Download update version 0.1v


Fixed continuous palette swaps in late game overloading command queue.

Fixed scene and input handling while unfocusing and refocusing window.

Fixed mouse pointer conflicts with window border or unfocused window.

Fixed wholesome copy palette not working when current slot inactive,
or when cycling from first to last or last to first palette.

Fixed crash when trying to use last colour of palette.


Changed Shift-Pick to Alt-Pick for assigning selected colour to current slot in palette.


Added forced copy marking with Shift-Pick.
Use this to copy a single cube or even partial cube selection.
(e.g. to copy a cube with different coloured sides at once),

Added Colour mixing.
Alt-Pick now mixes the selected cube colour into the current slot colour.
The colour is set literal/unmixed, if the current slot is inactive.
Alt-Ctrl-Pick mixes the selected cube colour into all Marked Slots (Enter).
(Note: holding key Alt now deactivates the tools Line, Add, Delete, Paint.)
Make extensive use of this new feature to build your palette on the fly.

Added horizontal scroll bar for palette swap to bottum of palette list.
Palette swap now only updates scene after you're fully done navigating.


Note:
In Ubuntu Linux, Alt-RightClick in a window is a default override shortcut
to open up a control menu. To deactivate this default behavior, use the free tool:
CompizConfig Settings Manager (get it from the App store), then go to the menu:
General -> General Options -> Key Bindings -> "Window Menu"<Alt>Button3,
and change it to a different key binding (simply disabling it may not be enough).

[NowvaB]

I made a space ship!
vrrrreeeeerrrmmm!! PEW! PEW!
Spoiler: ha! Nice try RAV!

Spoiler: From the side

Spoiler: From the back

Spoiler: Front Interior

Spoiler: Back Interior

Spoiler: Upskirt

I spent so much time learning how to use the program (Didn't read instructions) I didn't have time to make the ship cooler.
That, and I started to large.

Shame I can't save it. Guess I'll just let it sit on my desktop until winUpdate screws me over.

[RAV]

Woah! a space ship! Nice! I never made a space ship. Thx, Nova. Wish I could jump in. Pew pew.

Sorry for the inconvenience. Since the program core is starting to stabilize, I will soon be able to spend more time on improving accessability, doing video tutorials, and the save to file function.

Please note that you are using an out-dated version. I forgot to update the first post of this thread. If you are still interested, use the current >> BVT_v01v <<.

[RAV]

Test scene: Guild Halls.

[PixelPiledriver]

Nice work man!
I'm looking forward to further development and release.
 

[RAV]

Thanks, PPD. It's a pleasure to see you in action working your magic on stream.

There's still too much to do, but one day we'll throw down a pixel party.

[RAV]

Download update version 0.1w


Fixed input handling when refocusing window by other means than clicking it.

Fixed key Alt conflicting with key Ctrl for other functions than Line.

Fixed weird selection frame when changing selection size while holding key Alt.

Fixed crash when trying to manually flip / rotate while changing selection size.

Fixed some minor issues with hidden Gui mode and hotkeys.

Fixed insufficient precision of vertex coordinate arithmetic.

Fixed or reduced artifacts in the rendering of cubes (breaking seams).



Changed default Field of View from 90 degree to 87.5.

Changed world size from 15 to 16 levels.

Changed miniumum move speed from 9 to 8.

(The scale has a better feel to it now.)


Changed mini cams to no longer transfer grid mode to main cam.

Changed default mini cams to orthographic projection, until you set them manually.

(Use F1-F4 + b to reset mini cams to that default.)



Added Presentation view mode for scene overview. Use key p to toggle it on/off.

When in this mode, your view is set to orthographic projection,
and your controls change: press keys w, a, s, d, q, e to rotate scene.

Ctrl + rotation key to keep a little spin in that direction going on its own.
Doing that several times in the same direction speeds it up.
In the opposite direction slows it back down again.
Doing a manual rotation in same direction or opposite cancels the auto spin.
Press key Enter to pause/resume all spinning.

Combine different directions at different speeds.
Finding weird spin patterns is fun to play with.
The Presentation mode remembers your auto spin settings,
so toggle in and out to work on your scene or watch it.

Shift + rotation key for one step by 45 degree.

You can swap palettes (arrow), toggle grid (tab),
reset view (b) and toggle mouse (spacebar) as usual.



Note:
Since Blackbox scale operates at the computational limits of computers,
we are wrestling with precision failures that cause artifacts in the rendering.
This is mostly caused by the Bit limits in floating point vertex coordinates.
We could greatly increase the scale of the visible world even more,
but then we'd also have to deal with ever so more pixel faults.
The current setting are right at the edge of this, a current sweet spot.

If consumer graphics hardware moves from 32bit to 64 bit precision processing,
this would give us a lot more room with a lot less artifacts to deal with.

But if necessary we could increase world size dramatically even now,
by 16 times in axis length, 256 times in surface area and 4096 times in volume
of the current one here, and try deal with the pixel faults by scene design.

However, for the time being, the current settings seem appropriate enough.

[surt]

Have you tested double precision yet?
I think it's quite reasonable to expect the users of 3D graphics software have halfway recent/decent GPU.

[RAV]

Double precision comes at horrible performance breakdowns. Between 2 and 21 times slower. Even on the latest Hardware.
It also doubles the memory cost. So that would half the current amount of cubes.

I may reconsider at some later point, but the current settings seem to be best for the widest range of users right now, as an official version.
If you really want to see it working at mindblowing galactic scale, I may release special test versions, so you can judge benefits vs problems for yourself.

[RAV]

The Blackbox principle immortalizes pixel art. It's like the sentence of Pythagoras in math.
An eternal truth. Limitless. Never again can hardware outpace it.
Everything else is insignificant to its scale.
It is the law of the world.

No matter the screen technology or processing, this interpretation of pixel art adapts and trounces.
Its abstraction and virtualization of the grid distills the ultimate core creativity of pixel art.

Other trends and tricks in graphics may come and go. The basic pixel blueprint to the universe stays forever.

Godly pixel power. That spells judgment on all things. Tremble, mortal. For you have sinned against the sacred art.

[0xDB]

The Blackbox principle immortalizes pixel art. It's like the sentence of Pythagoras in math.
An eternal truth. Limitless. Never again can hardware outpace it.
Everything else is insignificant to its scale.
It is the law of the world.

No matter the screen technology or processing, this interpretation of pixel art adapts and trounces.
Its abstraction and virtualization of the grid distills the ultimate core creativity of pixel art.

Other trends and tricks in graphics may come and go. The basic pixel blueprint to the universe stays forever.

Godly pixel power. That spells judgment on all things. Tremble, mortal. For you have sinned against the sacred art.

Always nice to feel like that about something. What kind of pixel precision issues are you talking about though? (didn't notice anything odd in that last gif)

[RAV]

Ya, gets me all fired up. Good carry through all the shit. This issue is pretty much fixed now in the current version release on which this media is based on, to a point I consider it no longer relevant for the current scale settings. You'd have to try hard finding some stray issues when mucking around. But up until the last version it could get nasty too quickly when you painted on a cube that's not coloured wholesome, by way it breaks up and slightly reveals hidden surfaces of different colour as seams between cubes, when the precision of calculations isn't enough. Wasn't a dealbreaker though, it could be worked around. The Guild Halls video was on such a faulty version, and it wasn't something you'd notice in it. So if we were to massively increase size right now, the issue would just come back as it was before. Maybe that could be taken as an acceptable trade off, depending on the kind of project done with it. But my goal right now is getting the tool fixed from issues, finding sweet spots all things considered, and a minimum viability. Later we can see where to expand and bend things if need be, try whacky stuff.

I once suspected it might be the depth buffer being too imprecise. It's the first problem to think of as obviously connected to scale. But never made sense, since it got worse near, not far. Depth buffer is most precise near. Increased depth buffer from 16 to 32 bit anyway, since we need everything on this scale. The issue with floating point precision on vertex coordinates is a mixed bag of problems and how to deal with it. Depending on your settings and demands, how close you get, any vertex always kinda wobbles a little around on some level, it's just a matter how relevant that math is in the end for the final scene render. When we want absolute scale while pixel art has a high demand for clarity in its bold choices, it gets disturbed especially hard, so we gotta be careful here. Right now, by way the tool is designed overall, it works out well enough as is.

This whole thing isn't so much a problem with CPU dependent calculations on the scene, btw. Like for hit trace, which clearly works to highest standards. That's because doing double precision on today's CPUs is no big deal, whereas it very much still is on current GPUs. (though doing a hit trace that performs this well on scale still was kinda big deal, but for other reasons)

[RAV]

Download update version 0.1x




Fixed how palette modification is supposed to work in Presentation mode.

FIxed mini cams in windowed mode when returning from presentation.

Fixed unintended auto-rotation on manual when in free mouse mode.

Fixed movement speed for all directions.



Added basic animation by frame.

key Plus/Minus for going to next/previous frame.
shift + Plus/Minus to insert new frame between current and next or delete current frame.
ctrl + Plus/Minus to copy content of current frame to the next/previous frame (overwrite).
shift + ctrl + Plus/Minus to insert new frame and copy current content at once.
Alt + Plus/Minus for swapping current frame with next/previous, instead of overwriting.

Keys Period/Comma are synonym to Plus/Minus.

Keys * or / for increasing or decreasing the timing of frame.
shift + * or / for modifying the step size for an increase or decrease.
The timing is copied over with a frame.

keys m or n is synonym to * or /.


To watch your animation press the number key 0 (toggle).
Or go into presentation mode with key p;
you can combine the animation with rotation.


Your colour palettes are global for all frames.
But each frame can have a different palette assigned.


The cube count is also global for all frames, instead of per frame.
That means you can have more or less voxels on different frames.
Use this to distribute your pool of cubes where needed most.
This way you make efficient use of memory.

Current maximum frames is 300. Even though you can freely distribute cubes,
the more frames you use, the less cubes can you spend on a single frame.
Using 300 frames means, each frame can't have more than 5000 cubes.
Having 1 frame means, you can spend all 1500000 cubes on it.
Having 10 frames means, you can spend 1450000 cubes max on any one of them,
or distribute these cubes in any other way you like across these 10 frames.


Note:
Animation is still rudimentary.
It needs a more "gridless" copy of cubes.
The GUI needs a greater upgrade for more info.
But even though it is slightly awkward and disorienting,
seeing how frame animation interacts with the rest is interesting.

[Naret]

could you show some screen or vid of the precision artifacts?

[RAV]

Sorry, I'm late.

This was how it sometimes looked before the fix for the current size settings:



However, even for larger sizes this can be avoided by painting most cubes wholesome instead of different colours by side.

When going way too large on the settings though, the geometry just goes totally haywire.

[RAV]

Download update version 0.1y


Fixed crash when a frame exceeds its voxel capacity.

Fixed palette management corrupting other frames.

Fixed possible issue with selection on frame switch.

Fixed palette transfers not updating other frames.

Fixed new frame palette not set to current palette.

Fixed colour manipulation while in animation mode.

Fixed boundaries in mass colour modification.


Changed number of slots in palatte from 1024 to 256.
(may increase again later if necessary, but want to see this play out first.)

Changed default frame time modifier step from 25 milliseconds to 1/60 fps.


Added File System. You can now save to file.

key F5 for saving model and palette to file save.bvt
shift + F5 for saving only model to file save.vmp.
ctrl + F5 for saving only colour palette to file save.vcp.

key F6 for loading model and palette from file save.bvt.
shift + F6 for loading only model from file save.vmp.
ctrl + F6 for loading only colour palette from file save.vcp.

The file system allows for many changes while keeping backwards compatibility.
Your old work files will always be usable in newer versions of Blackbox.

Currently the file sizes are relatively large, at about 85 MB for a full scene.
And loading a maximum scene may take several seconds, during which the program seems to freeze.
File sizes and load times will be greatly improved in later versions.

It is possible that a person saves a full scene work to file and gives it to another person.
The other person may have less video memory than the first. In that case the scene cannot be fully loaded.
Though it will try to salvage and load as much as possible from the scene as fits into the smaller memory.

[RAV]

could you show some screen or vid of the precision artifacts?

Sorry, I'm late.

This was how it sometimes looked before the fix for the current size settings:



However, even for larger sizes this can be avoided by painting most cubes wholesome instead of different colours by side.

When going way too large on the settings though, the geometry just goes totally haywire.

Download update version 0.1y


Fixed crash when a frame exceeds its voxel capacity.

Fixed palette management corrupting other frames.

Fixed possible issue with selection on frame switch.

Fixed palette transfers not updating other frames.

Fixed new frame palette not set to current palette.

Fixed colour manipulation while in animation mode.

Fixed boundaries in mass colour modification.


Changed number of slots in palatte from 1024 to 256.
(may increase again later if necessary, but want to see this play out first.)

Changed default frame time modifier step from 25 milliseconds to 1/60 fps.


Added File System. You can now save to file.

key F5 for saving model and palette to file save.bvt
shift + F5 for saving only model to file save.vmp.
ctrl + F5 for saving only colour palette to file save.vcp.

key F6 for loading model and palette from file save.bvt.
shift + F6 for loading only model from file save.vmp.
ctrl + F6 for loading only colour palette from file save.vcp.

The file system allows for many changes while keeping backwards compatibility.
Your old work files will always be usable in newer versions of Blackbox.

Currently the file sizes are relatively large, at about 85 MB for a full scene.
And loading a maximum scene may take several seconds, during which the program seems to freeze.
File sizes and load times will be greatly improved in later versions.

It is possible that a person saves a full scene work to file and gives it to another person.
The other person may have less video memory than the first. In that case the scene cannot be fully loaded.
Though it will try to salvage and load as much as possible from the scene as fits into the smaller memory.

Wooopsie.... let's try again.


Download hotfix v0.1z


Fixed index corruption when moving palette.

Fixed frame time precision.

[Naret]

Sorry, I'm late.

This was how it sometimes looked before the fix for the current size settings:

Seeing your former wireframes and seen this, I think the issue you have is called "T-junctions". It can be partially blamed to the limited precision of digital numbers, but even in real life you cannot represent some values simply by reals. e.g. 1.0/3.0 == 0.333333....
(I'll avoid a long/boring explanation, derailing your dev-thread, but let me know if you want to hear it )

On the positive side, that issue was well known for a long time. (e.g. BSP compiler ran into it). The solution is called "half edge" data structure (or "representation"). You simply extend the way you represent meshes a little bit. Instead of having faces (in your case probably always quads) that hold references to vertices, you introduce a step in-between by referencing to 4 edges that reference to the vertices. (quads->faces[4]->vertices[2])
For rendering, you need indices and vertices, of course. But that's very easy to generate from the half edge representation. The BIG advantage is that edges are shared between two adjacent faces (quads). if you "Split" an edge, your both neighbour will realize this and can generate an index/vertex mesh with taking this split-vertex into account.

The way I've implemented it is to have a "flag" in my "edge" struct that specifies whether the two referenced items are vertices or the two sub-edges from a previous division. This way, during "splitting" I don't even care about the neighbours, as these implicitly will know about it when you bake the half-edge-mesh into a triangle mesh.

there is a lot of further reading of about it, a more visual and practical guide: http://www.flipcode.com/archives/The_Half-Edge_Data_Structure.shtml

It might look a bit exhaustive at first, but it actually is quite simple to implement, BUT this will eliminate 100% of the issue, worth the effort IMHO

[Naret]

sorry for the double post, I think there is no "edit".

An alternative to meshing is "direct rendering" which bypasses this issue completely and opens up a path to a new world of fun

I don't have that many screenshots of it, but here is one where you see some high density recursion next to a very low density and there is no precision error. (in general you work with volumes and not with faces, hence it's hard to create a gap in-between)


it's simpler that meshing.

[RAV]

A well informed and goal oriented contribution. Thank you for your time.

As mentioned, the problem is solved for the current map size and detail level, which is much larger than what is typically done in classic bsp. Don't underestimate just how absurdly huge the scale in pure geometry really is, and all of that in one single scene on screen. Blackbox operates differently from what you assume. The explicit vertex data is in fact unambiguously and perfectly aligned in a way that floating point precision is not a factor in this at all -- not at this stage; though bit length of data is relevant for total number of sub division levels. But it's in the actual rendering calculation of the graphics chip processing each single vertex to the actual camera settings where the floating point precision comes into play and falls apart, and at some point there's no solution to this, other than upping the bits of the render processing itself. This is why mechanical CAD engineering traditionally renders in 64 bits, and there were special and very expensive lines of graphics cards made for this. That's also why some recent games that rely on extreme scale go for 64 bit despite the runtime costs on consumer cards. There's a point in scale so extreme, no data structure can compensate. And Blackbox ever so much scratches on that.

However, Blackbox remains a heavy WIP in all aspects, and the rendering is due for an upgrade sometimes next year. This will notably push its capabilities further. It will most likely stay based on meshes. Thinking the specific principles of Blackbox through, it makes the most sense so far.

[Naret]

You say Blackbox operates differently from what I assume, and your description didn't make it 100% clear to me, hence allow me to ask: Do you have t-junctions in the mesh?

[RAV]

Blackbox does not deal with arbitrary vertex coordinates like bsp does, it is not at this stage that precision is an issue and vertices would start to accidentally differentiate or conflate. But what you describe is relevant in the form of that vertex indexing could possibly still somewhat help even on level of gpu processing, by way it may perhaps cache some part of the individual render calculations. However, there's reasons why I don't do this. Since Blackbox is still wip, there is a specific goal I have with it, and in the end the vertex data will no longer describe meshes in the classic sense, but the meta data required to generate these meshes on the fly, such that neither t-junction nor explicit vertex indexing are planned to factor in.

[Naret]

ok, so you have t-junctions currently. That's why you see the typical artifacts.
t-junctions become a problem on the rasterizer stage, after view projection. it's not dependent on the mesh alignment.
There is a nice explanation for "aligned meshes" aka voxel:
https://blackflux.wordpress.com/2014/02/23/meshing-in-voxel-engines-part-1/

I'm not sure what it means, but I'm very curious to see your future on-the-fly meshes and how you'll overcome the t-junctions

Voxel <3

[RAV]

Thanks, Naret. You're a good read and the links you give valuable resources.

Since that patch I haven't encountered this problem anymore, and if it is there it might be just a single stray pixel on the HD screen, practically unnoticeable. So it has become low priority compared to other concerns, such as greater optimization of memory and performance. I think the reason for why it works out so well right now is that not only are the values for coordinates aligned on a regular grid, they are well-defined, clean, simple, short values by themselves that have a lower chance to provoke trouble in the math, and so leave a lot of headroom in precision for the renderer's own calculations.

The current scale gives me a lot of advantages in further crunching down on memory, and seems to strike a nice balance in size and the voxel count I'll aim for. So considering all that, I currently don't feel inclined to push it further. But if I do, I will have to look for strategies such as the ones you suggested, to make the most out of the significant precision range for a maximum of subdivision levels on the given type's bit size.

[RAV]

Hrrm, but I'm still not settled on the issue. It may still turn out that the things I had originally in mind prove a failure or not worth it in comparison. It's possible I will have to resort to more classic meshing strategies such as described in your latest link. It may turn out that it would simply end up the best of both worlds with the least of problems, all things considered. But we'll have to wait and see. It's a long road, a lot of work.

[RAV]

But it keeps being a tough question. It's trade offs of problems really. The reason I avoided automated mesh optimizations is because of how much it adds runtime costs on model manipulations. Even though there is a variety of methods with more or less costs, even the fastest does add a substantial amount. Blackbox tries to keep that experience more fluid, and rather relies on the artist to sufficiently optimize the grid manually by multi-resolution construction. The poly count of that is less ideal than by auto mesh methods that go beyond cube form. So it's a question of framerate costs in that versus latency on model changes. Add to that, I've grown to like the current cubic organization of the grid composition from a work perspective. The plans on how to optimize memory differently aims to keep that. And rather have artifacts compensated for at no costs by raw precision range. Balancing all these considerations is a difficult question. For the time being I will keep going with the current approach, to concentrate building the rest of the core features. At some point though, when seeing it all play out, a decision must be made which kind of costs we'd rather settle with, or which kind of costs gets along best with the specific case of application. Maybe even multiple render modes for choice. Hrrm.

[RAV]

Thanks, Naret. You're a good read and the links you give valuable resources.

Since that patch I haven't encountered this problem anymore, and if it is there it might be just a single stray pixel on the HD screen, practically unnoticeable. So it has become low priority compared to other concerns, such as greater optimization of memory and performance. I think the reason for why it works out so well right now is that not only are the values for coordinates aligned on a regular grid, they are well-defined, clean, simple, short values by themselves that have a lower chance to provoke trouble in the math, and so leave a lot of headroom in precision for the renderer's own calculations.

The current scale gives me a lot of advantages in further crunching down on memory, and seems to strike a nice balance in size and the voxel count I'll aim for. So considering all that, I currently don't feel inclined to push it further. But if I do, I will have to look for strategies such as the ones you suggested, to make the most out of the significant precision range for a maximum of subdivision levels on the given type's bit size.

Hrrm, but I'm still not settled on the issue. It may still turn out that the things I had originally in mind prove a failure or not worth it in comparison. It's possible I will have to resort to more classic meshing strategies such as described in your latest link. It may turn out that it would simply end up the best of both worlds with the least of problems, all things considered. But we'll have to wait and see. It's a long road, a lot of work.

But it keeps being a tough question. It's trade offs of problems really. The reason I avoided automated mesh optimizations is because of how much it adds runtime costs on model manipulations. Even though there is a variety of methods with more or less costs, even the fastest does add a substantial amount. Blackbox tries to keep that experience more fluid, and rather relies on the artist to sufficiently optimize the grid manually by multi-resolution construction. The poly count of that is less ideal than by auto mesh methods that go beyond cube form. So it's a question of framerate costs in that versus latency on model changes. Add to that, I've grown to like the current cubic organization of the grid composition from a work perspective. The plans on how to optimize memory differently aims to keep that. And rather have artifacts compensated for at no costs by raw precision range. Balancing all these considerations is a difficult question. For the time being I will keep going with the current approach, to concentrate building the rest of the core features. At some point though, when seeing it all play out, a decision must be made which kind of costs we'd rather settle with, or which kind of costs gets along best with the specific case of application. Maybe even multiple render modes for choice. Hrrm.

Hrrmm. But I must say, considering all the particular circumstances of the Blackbox paradigm, the scale of selection, amount of world changes, absolute multi-rez, different segmentation strategy, multi-dimensional requirements, block morphology, etc pp, it is highly unlikely that any automated mesh optimization method can deal with appropriately and at acceptable costs, compared to what may work in other voxel applications. It is most likely I'll have to stick with the plan and accept T-junction as natural byproduct of all the other features that will make Blackbox interesting, and have the settings take sufficient care of artifacts by decently spaced precision buffer. Most likely that means keeping the current 16 subdivision levels on 32 bit rendering, and 32 levels on 64 bit that may in the future come to market. Nothing's ever set in stone, but that seems right now the best course of actions. Well, but at any case, it would really be nice if I could bring myself to get more menial tasks done first, like a proper GUI for example, it's starting to get somewhat embarrassing.

[RAV]

It's been a good talk. I understand now better what you were trying to say in your first post, by example of bsp. The lesson here is: vertex indexing is not only important to save memory, but to get more use out of the value range from the given precision in the renderer. It's not by chance that this is the usual standard in a 3d pipeline. It is unfortunate I couldn't yet find a method that satisfied me on other requirements. But maybe I will some day. Or find appropriate trade offs.

[Naret]

The reason I avoided automated mesh optimizations is because of how much it adds runtime costs on model manipulations. Even though there is a variety of methods with more or less costs, even the fastest does add a substantial amount. Blackbox tries to keep that experience more fluid, and rather relies on the artist to sufficiently optimize the grid manually by multi-resolution construction. The poly count of that is less ideal than by auto mesh methods that go beyond cube form. So it's a question of framerate costs in that versus latency on model changes. Add to that, I've grown to like the current cubic organization of the grid composition from a work perspective. The plans on how to optimize memory differently aims to keep that. And rather have artifacts compensated for at no costs by raw precision range. Balancing all these considerations is a difficult question. For the time being I will keep going with the current approach, to concentrate building the rest of the core features. At some point though, when seeing it all play out, a decision must be made which kind of costs we'd rather settle with, or which kind of costs gets along best with the specific case of application. Maybe even multiple render modes for choice. Hrrm.

I agree, a fluid working tool is very important; what is the fastest and most correct rendering worth, if you cannot edit it?

A lot of time there is no just 1 good solution, so I would suggest you have 2 modes, one for editing and one for correct rendering. (A lot of engines, e.g. Unreal Engine, Source Engine, etc. have two modes).
I think nobody cares during editing about the precision artifacts, because they know it's just in editing. In gameplay mode, you can run high-quality meshing and optimizations, because you need to do it just once.

[RAV]

Yes, you're right. I'll have to deal with the mesh more properly some day. Hoped I could kinda ignore that, but probably can't. The issue with artifacts is not super bad right now, but it isn't quite as negligible as I wanted to believe and made it sound. Even 64 bit rendering, though it may help, wouldn't completely eliminate it. Its main benefits would be simply a much greater total number of size levels possible, but not fully address the artifacts on its own. However, resolving this issue is not in my immediate reach right now. I'll have to wait it out for a while and take care of other things until I'm ready for that.

Thanks for your input, Naret. Took me a while to come around, but I'm a bit stretched out with stuff.

[RAV]

Download BVT_020


Fixed unnecessary loads or saves, and button mashing on Load/Save stacking up.

Fixed crash on load/save to a file that was deleted in an active session.

Fixed dangling and backup problems with open files.

Fixed current colour not reseting on palette load.

Fixed conflict of running animation on load.


Reduced remaining artifacts.

Reduced file size by 75% for same amount of voxels.

Reduced runtime memory and improved management on same amount of voxels.


Increased maximum voxels from 1.5 million to 3 million.

Increased maximum frames to 600.


Note:
Loading a full scene can take very long now.
Be patient. Expect more improvements upcoming.

When a single frame has most of the many cubes,
palette changes on it have a noticeable delay.
Though this will be fixed in a future upgrade,
working with such a large scene is strainful at any case.
The true purpose of the greater cube count is to have
more material for animations across multiple frames.

[RAV]

*sigh*

Download hotfix BVT_020b

Fixed geometric breakdown on smallest size levels.

[RAV]

*double sigh*

Download hotfix BVT_020c


Fixed smallest voxel size level not saving correctly to file.