Panicle - Minecraft Schematics to Qubicle files (and more!)

How do I get this? I don’t think you said.

The link was at the very end of the first post. It should be pretty easy to find.

Really? I thought the .qb format was meant to be a secret based off a previous attempt to figure out how it was formatted being heavily discouraged I believe.

EDIT: Doesn’t matter, I found the thing I remembered and it was .qmo not .qb so it’s all fine.

the usage, requirements and download details are in the original post…

or did the steps to get it working not make sense, perhaps?

Oh, whoops, didn’t see the download link!

Yepp, qmo is supposed to be secret. Which makes sense when you think about it, since qmo-to-qb would allow everyone to use the free version. Therefore, I think some crude qb-to-obj converter wouldn’t hurt too much since I would not go lengths to make it optimized or anything. It would be enough to animate stuff, but that would also likely be about it. It wouldn’t produce .objs that could be used in other games.

I’ve uploaded the new version. There’s nothing too fancy in it; it has support for multiple files (either by just dragging them or doing Panicle file1 file2 file3 file...) and allows to set blocks to false in the blocks.json. Blocks that have been falsified will be treated as void. The included blocks.json has an example for that, which voids glass blocks.

Another idea would be that we could perhaps split the MC schematic up into different qbs/matrices. This could allow us, for example, to separate a house: One matrix for the solid blocks, one for the glass. The glass matrix could then be rendered with a special effect, making the glass really transparent.

I would need some info on the system though, especially whether I can simply add another matrix into the qb or if I need independent .qbs for that.

What’s confusing about the system? I thought it was fairly self explanatory from the Psuedocode sample. Just increment the matrix count value in the header and add another matrix to the end. The only hard part for me was figuring out they were using run length encoding as I didn’t read the header very closely so I figured it out from the code.

Also what about using the minecraft colour palette they provide as the basis for the imports? I’m not sure what it actually has though.

There’s nothing confusing about the system…? How did you get that idea now? If you think about the glass/matrix deal, I’m not talking about Qubicle, I’m talking about Stonehearth’s engine and its approach to models.

What? There’s a colour palette? To my knowledge, Minecraft blocks are defined by a model (if even) and a texture - there’s nothing (official) that maps blocks to a color.

For models with multiple matrices I’d suggest looking at the critters like the rabbit or the mammoth that only have one .qb file but are animated.

As for the colour palette’s I was talking about this, on the wiki .qcm’s are provided for the export to schematic feature.

The question is more what multiple matrices do - i.e. if I can have one matrix rendered with shader A and another matrix rendered with shader B. Panicle already supports multiple matrices (read and write), I’m just not using it yet.

Qubicle’s palette is - in all likelihood - completely useless. It’s merely defining the colors supported by the exporter, it doesn’t map to Minecraft blocks per se.

Edit: 15:44, I’m trying to understand Qubicle’s Alpha encoding. It’s odd.

The increasingly green part are blocks that Qubicle’s and my definition of “visible” differ, the blue blocks indicate the difference. In every occasion, Qubicle thinks that the blue blocks are “blocking”, i.e. the green blocks are not visible from the blue side. This is obviously wrong, because it’s just the opposite of the front - where the same algorithm worked fine.

DIFF: LeftVisible #0
Expected Available, RightVisible, FrontVisible, got Available, LeftVisible, RightVisible, FrontVisible
0/1/9
DIFF: LeftVisible, TopVisible #255
Expected Available, FrontVisible, got Available, LeftVisible, TopVisible, FrontVisible
8/8/9

Just to name two (the very first in the bottom-left corner and the top-right corner. Am I supposed to assume that the back of the model (and the bottom) are actually not visible?

Debugging this without access to the model itself is kind of annoying.

Edit: 17:00, I’ve managed to fix the oak log. Turns out that I’ve had switched the original and mine - i.e. my version was lacking flags (curses, <=). However, the trees are still broken - I guess all more complex models are. The investigation continues…

Edit: 17:43; there we go. I was trying to be super-smart and failed horribly. My approach to check visibility was to see if the voxel was actually reachable from the border - which is completely fine and probably a better approach for solid objects, but fails horribly for translucent objects (you would get a Minecraft-Glass/Water-like effect, where you could not see the “back” side or “content” of an entity).

So I went back and changed all the code to use a completely simple check-all-sides and lo and behold, I’m getting the same results.

If you have no idea what I’m talking about; try to fly through a large oak tree. You’ll see that there’s a trunk “hidden” inside.

I’m not sure if the graphics engine renders them even when they’re not visible (I would guess… no?), but either way it’s impossible to see them; they are wasted voxels. Panicle can find those hidden voxels and remove them.

It’s not live yet, but Panicle has now support for visibility mask encoding.

That’s what it looks like once Panicle “”“optimized”“” it. Note that this was all pretty much wasted effort; Stonehearth’s engine doesn’t care for the Alpha visibility optimisation. However, stripping those useless voxels might do something. I don’t know and I’m not going to bother; the code is going to stay but it’s going to be conditional’d to debug builds - which means that this whole optimisation won’t be possible with my distributed release builds.

However, this whole optimisation might prove useful if you plan on porting over Minecraft stuff - which is still Panicle’s #1 task. So I might add it there, I’m not sure yet.

Edit: 19:13, to make our task easier I’ve decided to implement png-to-qb, which takes a (square) png and transforms it into some sort of qubicle file, similar to how Minecraft handles these things. That would allow us to create simple png textures that can then be converted to Qubicle files that can be used to build Minecraft structures in Stonehearth.

So, err.

block.png → block.qb
block1.qb + block2.qb + … + TempleOfGeoffers.schematic → TempleOfGeoffers.qb.

Edit: 21:55, I’ve been playing around with it a bit. The default of 16 pixels per block (Minecraft-resolution) is definitely not viable… We’re looking at 60 MB qbs here for the Cart. Sooo, err… Yes. I think 4 pixels is more than enough…

1 Like

so it is spelled, so shall it be built…

thanks for plugging away at this! I hope to have a go at it this weekend… :+1:

I see…we were just a harmless fling…and don’t tell me that whole thing with that Timber & Stone is still going on too? :cry:

1 Like

#Update (1.2.1.0)

Multiblock feature now available

I’ve chosen that, for my experiments, a 6x6x6 block should do. It kind of does. Keep in mind that there are memory limitations though. You’ll have to find them yourself.

So, what it effectively does: If you rename a .schematic to .pansmatic, Panicle will try advanced magic. It will search for “block_ID.qb” and “block_ID_data.qb” files (for example, “block_4.qb”, “block_17_8.qb”. Those files must be cubes (width == length == height) and all must have the same size. It will still read the blocks.json and just fill in those colors if no specific block qb has been provided - so you can have only certain blocks replaced.

This is now using the advanced optimisation that I spoke about earlier. Right now, it will run on half as many threads as processors are available - the whole process scales quite nicely, so the bigger your creation gets, the more CPUs you want…

So anyway. To use this feature:

  1. Rename your .schematic to .pansmatic
  2. Make sure you have all blocks either defined in the blocks.json or available as “block_id_data.qb”.
  3. Drag-and-drop the .pansmatic. Remember that Panicle will look for the blocks in the same directory as the pansmatic, not the directory Panicle is located in.

To make the creation of those blocks easier, I present

Block creator

You’ve seen the blocks already above. These were the textures used to generate them (scaled by factor ten).

If you drag-and-drop such .pngs onto Panicle, it will create a cube that somewhat looks like the texture you’ve defined. Remember that unlike in Minecraft, the edges have to share their colors. I’m not sure how to solve that issue, right now, it’s first come first served - so one face will always overwrite the others. Perhaps that should be blended somehow…

But anyway, a simple way to create blocks. The size of the texture defines the size of the block; a 6x6 texture will create a 6x6x6 qb. The texture must be square.

Axis view & multi matrix support

Track:



Cart (unscaled):

Both implemented. Files with multiple matrices will be dumped as “qbfilename_matrixname_axis.png”, just like before. With those three axes, you get a real idea of what your model looks like. It’s really fancy.

Sooo, err, yes. This update effectively rules out the possible features “Optimize qb files”, “Multiblock scaling” and “Multimatrix/Multiaxes”…

1 Like

Wow… this… this is brilliant. I could probably make much better models with this… starts thinking of new ideas

There’s three features that I am currently debating whether or not to include them. One of them is the reverse of the axis split - i.e. you define an image (like the one currently exported), tell it how many slices it is and Panicle merges them together to a qb file. This would allow for very easy and quick re-skins, especially for small objects.

The second would be a qb merger. Basically, it merges matrices from A.qb with the matrices from B.qb - to allow stuff like human models being built with Panicle.

The third would be an obj exporter.

All of these things would, however, heavily get into Qubicle’s own domain… which is something I want to avoid.

your caution is appreciated… perhaps a conversation with @Tim is in order?

1 Like

Probably. I think some of the things Panicle already does (or will be doing) are actually features in Q2. Soo, yes. !summon @Tim?

2 Likes

Hey guys, here I am.
First of all: posting such a tool first, and asking whether it’s okay later, is obviously the wrong way. As soon as you post it somewhere as crowed as this forum the damage is done. I just say this because a lot of modders out there think that it’s okay to hack everything related with voxels because games like minecraft allow this. But that’s simply not the case. You can even break the law. So, think first, then ask the developer of the tool for permission and then finally, if he allows it, post it. I appreciate your enthusiasm but please play fair, and stay out of trouble. You have scripted this in a couple of days but the developer of the software might have invested years. Once again: as soon as you post it, it can’t be undone.

Sorry for the long introduction but I needed to say this.

In this case you haven’t done anything illegal because the qb file format is open. Still, I would have appreciated it if you have contacted me before posting it. And it would be nice to wait with the qb to obj exporter until I release Q2, because that indeed does go heavily into QC1’s domain.

And yes Q2 will have a minecraft importer, that’s true for all Qubicle 2 editions. Higher editions will also have a poxel mode, so the blocks are rendered with a texture and you will be able to use minecraft textures or whatever you like. And finally the Qubicle 2 Play editions will feature a very basic 1-click OBJ exporter.

Cheers!

1 Like

I know that it’s impossible to undelete things from the internet (and more often than not, trying to do such a thing results in the exact opposite). It was never my intention to hurt you, Minddesk or Qubicle, the same way I never intended this to be some sort of “free” replacement for any of the tools you provide.

I did a little bit of research about the possible consequences of releasing such a tool, I didn’t just upload it. While I’ve missed that Q2 will have such a feature (which upon retrospect would be a good argument against a release), I thought that since qb was an open format and I was not replicating any (currently available) function, it would be fine. I suppose I should have talked to you in advance about it, but I was a little bit too excited about getting it to work.

As per your request, I’m not going to release the qb-to-obj exporter nor the other features I’ve coded in the meantime - so effectively, I’m stopping the project. It has all the features that I’ve wanted it to have in the beginning - so that’s enough for me. I’ll keep it closed source too, just to be safe.

Even though it might be too late - if you want me to pull the plug completely on this, I’ll gladly do it.

4 Likes

Hey, you don’t need to pull the plug.
I know you didn’t want to do any harm and you didn’t. I just wanted to give an impression on how it feels like from my point of view. Like I said you used qb and that’s fine. Somebody else hacked qmo and that is so unbelievable frustrating. You can’t believe that somebody is actually capable of doing such a thing, I mean I am not Adobe or some other big company. Maybe that’s why I needed to say this.
I can totally understand your excitement, that’s the reason why I am working on this project for such a long time now. Please don’t feel discouraged by my comment. If you just skip the obj part that’s fine with me.

7 Likes

Hey tim, will stonehearth ever include qb or will it always be seperate?