simlu / voxelshop

This is the official repositiory for VoxelShop

Home Page:https://blackflux.com/node/11

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Proper use of Bounding Box

iamfunsho opened this issue · comments

Currently the bounding box is not very much in "use" cause one can still draw outside the bounding box. In reality since voxelart is similar to pixel art and the bounding box should serve as a canvas (like in 2D). It would be nice if bounding box was the only "drawable" portion, not only will it be a good usability improvement, it would also optimize/improve most internal features eg the exporter and #210.

At most I would replace it with an infinite floor where you can draw voxels, I use box wall currently to take height to my project because i can not draw on Y axis (instead of clicking so much on a tower of voxels)

That will be a disaster if we implement the face tool, so i think it wrong

The best solution is to set a reasonable size as the default bounding box eg 126, you can then expand it (currently supported) to fit your needs.

Why face tool is a disaster? How can I expand the bouncing box?

In simple term the max size supported by voxelshop is the max size of an Integer. If we made the ground that size, using the face to fill the ground like in MV will probably crash on most computers. There is an arrow button below the bounding box button, clicking on the button will show the input for changing the bounding box size, I wonder why such an important function was hidden behind a button.

this limit comes from Java?

Something that really worries me is VS performance, I tested those days Magica Voxel and I really can build complex voxel art more faster than in VS (more faster, but the result is less efficient for games)

In Voxel Shop a simple project of 400 voxels begins slowing down the program on my computer (i7-4720HQ, nvidia GTX 970M, SSD rom, 16 Gb ram DDR4)

I use PHPStorm commonly (based on Intellij IDEA, built in Java too)

Some years ago they have several performance problems but finally they solve this (I did not followed their development so I do not know how)

Intellij IDEA is open source so probably you can learn something from their repo (how they manage large files or how they manage program task or if they are using some libraries for performance)

Android Studio (by Google) is based on Intellij IDEA too

Yeah the limit is from java. Magicavoxel will be faster than voxelshop due to fact that most of it current limitations were due to performance consideration e.g it 126 max size and it was written in c++ (although that doesn't matter much). It's true that VS begins to get slow when working with large models and even Magicavoxel that am running via wine tends to perform better but i think that's due to multiple reasons and i wish simlu would be able to look into this.

I'm a little lost with performance I do not know how to improve this part, it requires more deep knowledges, but sure with all our help @simlu will find the way to solve this

No no no, the issue does not come from Java. There are two parts here:
(1) Data structure
(2) Rendering

Why you are currently experiencing slowness is bc of rendering. I'm using a software renderer to be compatible easily with all os.

The next step then is to change the data structure. That is important for undo / redo operations and for really large objects...

Im planning to address rendering first.

Sounds nice @simlu

Nice to hear, but the limit i was talking about was Integer.MAX_VALUE., read my older conversation

Yeah, that's an implementation detail and not the reason why it's slow. In general you are right, but it's not the limiting factor here.

Nooooo, am not saying that's why it's slow, am just saying making the default ground size that amount will be unrealistic and will probably cause more issues.

There is an implicit limit ~pow(MAX_INT, 1/3)

Im not opposed to an infinite ground... Not sure how it would display.

Never saw that :D.. Infinite ground? Are you not bothered about performance?

Well, by infinite I meant ~pow(MAX_INT, 1/3)

not infinte, but if it follows the camera movement? like side-scrolling games

anyway, I do not know that I can change their size, with this option bounding box is more than done to go

A infinite floor does not needs attention at this moment

I'm reworking milestones atm around performance improvements. Closing this as it went way off of topic. Created a new issue here: #216