Troxel - a Voxel Viewer HTML5 WebApp

Introduction to Troxel - a Voxel Viewer HTML5 WebApp##


Hi, some time ago I started to create a webbased Voxel Viewer (and Editor) inspired by another voxel based game - Trove. Since yesterday I’m at a point were I can consider the Voxel Viewer part of my project as stable, though the Voxel Editor part and it’s GUI is still a work in progress. Nevertheless I think it’s time to announce this project to the modding community of this awesome game creating an easy way for them to show off their creations in 3D.

Links:


  • IO (importing and exporting)
    • everything is done client side (static WebApp) using high performance JavaScript code
    • support for Qubicle (.qb) file format (including compression and other file options)
    • support for Magica Voxel’s (.vox) file format
    • support for Zoxel’s (.zox) file format
    • own file format allowing you to share your voxel models base64 encoded in a Link like this one (example model from Magica Voxel)
    • some optional Trove specific features like support for alpha, type and sepcular maps you can safely ignore
  • 3D-Voxel-Viewer
    • fast WebGL based renderer (can render even 120x120x120 big models @60fps on only an Intel HD4000)
    • multiple render options for lightning and wireframes
    • Orbital controls (left click = rotate, right click = pan, scroll wheel = zoom)
  • 3D-Voxel-Editor (still a work in progress, enabled by switching to edit mode in top right corner)
    • add / remove voxel mode (left click = add single voxel, right click = remove voxel)
    • fill mode (left click = fill singe existing voxel, right click = fill connected voxels with a option for same color only)
    • possibility to add a color noise (brightness or full hsl range) while editing (make big same color areas more interesting with some color variation)
  • libTroxel - a JavaScript library allowing you to embed 3d rendered voxel models in your own website (example)

##Roadmap:##

  • fly controls for big models (dungeons)
  • GUI rewrite (finally replace the old placholder GUI)
  • improving the Editor

##Addition Notes:##

The project is hosted on GitHub: GitHub - chrmoritz/Troxel: WebGL-based voxel viewer and editor
Feel free to check out the source code, open issues or open pull request (contributions are alway welcome).
Don’t hesitate to reply here or on GitHub if you have feedback, suggestions or if you found a bug or need help integration libTroxel into your own website.

13 Likes

This is really awesome!

1 Like

Very Cool =D and Impressive =]

I did however find bug: Thank you for fixing it =D


These were taken from the same relative angle. As you can see, The Troxel Model is turned around backwords, and the sword isn’t the the right spot… Perhaps when importing, your program isn’t taking into account the “handedness” pf the QB file?

Also it melds all the matrices together, which is understandable since, I think Trove models don’t usually have more than one…

Over all, really good job though =] I didn’t think that web-based voxel editing like this would be possible ^^

4 Likes

After a quick look through, the whole .qb implementation looks a bit non-standard (and therefore non-Stonehearth). But then again, Stonehearth has also some pretty odd rules on models, especially when we’re talking about animations.

Yeah the multi matrix support is quite untested, because I didn’t have to carry about it until now.
Which file is this? I will take a look and try to fix this. (I think I should have tested more stonehearth models than only some construction parts)
About the voxel orientation: From my implementations of the different voxel formats I can say, that there is a terrible inconsistency between the different voxel editors and programs using voxel files. I use for Troxel the same orientation Trove is using and convert files during import/export to/from this orientation.

As @chimeforest has guessed correctly, Troxel was designed only having 1 matrix qb files in mind, which are very well tested. On the other hand multi matrix support wasn’t really used so far and is quite untested. I have to admit that the Qb import code is quite complex because it has to handle all the multi material maps stuff used by Trove and that the bufferbased file IO can look quite strange if you only know readline based file IO so far.

It’s my Templar model which I have uploaded for you here.

Thanks, I found the issue: It’s the way I handle the matrix offsets while merging the matrixes for qb files with right handed z coords (left handed should work fine in the current version). Working on a fix now.

Edit: Looks like I handle right handed z coords inside the matrix correctly and the issue is in the way how right handed z coords is changing the way the offsets of the matrices to each other are handled. Sadly this isn’t well documented (the example implementation doesn’t handle right handed z corrds at all), so I have to do a little reverse engineering here.

BTW: At least Magica Voxel has issues with it too:


Edit: stonevox3d (at least the java based version) has issues with this too (@honestabelink you propably want to fix this too)

I can confirm that only multi matrix support for right handed z coords is broken. Left handed works fine as in this model: http://www.minddesk.com/wiki/index.php?title=Download_Test_Data

3 Likes

I have a fix ready, but I decided to take the chance and switch my renderer from left handed to right handed z coords. (At the beginning of the project I handeld a lot of left handed qb files, because this is what zoxel and magica voxel export to, but nowadays I handle more right handed z coords, even Trove uses right handed z coords, but they released the tools to export qb files after I made my IO implementation. But I think its worth to do the chance now.)
Sadly this will break compatibility to other voxel formats (because I made the assumption that Magica Voxels qb implementation is correct). So this requires some more work. The actual fix was quite simple, but now that I’ve changed the renderer to right handed z coorfs I have to change the IO of all other formats too to import to right handed coords and this stuff all needs a lot of testing to assure that I handle all orientations consistently even when all formats are defining their orientation in a different way.

I think I push the update that fix this sometime tomorrow. It should be ready right now, but I’m to tired to do some high quality testing…

3 Likes

@chimeforest: Fix is now live. Here is your Templar (open it in a new tab directly, because discourse doesn’t handle hash tags well on their redirect page) rendererd in Troxel.


Thanks for reporting this very specific bug (which only have affected multi matrix right handed z coords models which are using matrix offsets), which gaves me the motivation to change the renderer from left handed to right handed z coords (which is good for long term I guess) too.

7 Likes

No problem, thank you for fixing it and making this really cool app in the first place =]

2 Likes

Very good! I’m a little bit a little advice: 1, increase the “brush” feature, you can hold the left mouse button drag, so that it is painted. 2, the “matrix” layer, hoping to increase


The matrix of the layer:

3 Likes