I don’t see how converting to qb is borderline piracy to be honest.
it’s not like we steal any software or use it for any malicious goals, converting to qb just allows us to use the file.
It’s just like how GIMP can use PSD files, which belong to photoshop, the files are just really handy and widely used so it becomes a necessity for someone who doesn’t own the program to also have access to it.
Although I would like a dev’s commentary on this before I continue and will ask on the Qubicle forum.
Oh also, if it really is borderline it is a weird decision of the devs to limit us to .qb since that would limit us to Qubicle. Just like saying anyone who creates an image for a specific game should use photoshop.
It wouldn’t be piracy but there is the potential for copyright infringement as you wouldn’t be licensed for it. Although that might not be a problem either. I wouldn’t worry too much about that.
That is a good point, but my reasoning is that if the Qubicle devs want us to be able to make .qb files without paying, then the ability to export as .qb would be in the free version.
Yes but Qubicle isn’t just a converter, it’s a whole (epic) editor you pay for, not solely the .qb export function.
All I want is convert non-qb files (that aren’t generated by qubicle, I’m not taking their free version format and converting it to their paying format) to qb files.
Hey guys,
I am a bit worried that you already think about reverse engineering my qmo file format. The qmo file format is closed and tinkering with it is not only not ok because you would destroy my business model with this action and I need to eat, too. It’s simply illegal. The moment this happens there will be no free basic edition any longer but a 10 day trial. I am doing my users - that includes you too - a favor with the free basic edition, please don’t let me regret this.
As this post is 4 days old I hope you have read this one in the meantime:
There will be a solution everybody will be happy with.
Please stay patient.
Thanks
I was considering picking up the education version this week (yay perk of college) until I saw they are working on a version 2.0. Post said that you’ll have to completely re-purchase the new 2.0 edition, but they currently don’t have any planned released date. So my goal is just to use their free version, make some models, save them and then some day find a use for them. I just don’t see a point in spending $40-$80 for software that might be replaced before this game is released.
All else fails, I’m sure I can befriend someone that has the master edition, send them my files so they can export them in the correct file and send them back to me.
This may seem a bit necro but I’d prefer not to create a new topic just to ask the same question.
For my roof tiles for Archmod I need to rotate some of the .qb matrices and while it is possible via static animation effect, it generates quite a lot of unnecessary surfaces (like 60% of rendered surfaces per model). Memory-wise it would be better to use non-voxel model to do that as I could reduce poly count significantly. Does Stonehearth support any non-voxel model format? I know .obj was used in the past and some .obj files are still present in stonehearth.smod but they all have .qb counterparts. In manifest.json there still is: "models:arrow": "file(data/models/arrow.obj)",
and "stonehearth:proxy_model" component exists.
I would have thought SH supports triangle optimization for voxel surfaces. Imo this is not a format issue, unless we’re talking about loading times? Or are you worried that instance geometries are not used (again engine optimization rather than format issue)? Can you clarify your issue a bit more?
I have a .qb file with several matrices. I set up an animation to rotate some of these matrices and as a result a lot of surfaces is inside other matrices but they are still being rendered because they are visible prior to animation. As this object is a roof tile and I need to place a lot of them this is quite a problem. Using .obj instead of .qb would allow to get rid of unneeded surfaces completely.
Also, for Archmod Gothic style windows I’d like to have diagonal lines:
Actually, if I used .qb model for ghost and iconic entities and switched to .obj only for root entity it should work with outdated "stonehearth:proxy_model". The problem is I don’t know how to link .mtl file with .obj
(1) In that case I would make the geometry that will be inside other geometry as smooth as possible (make as few surfaces as you can). The engine should then only have a very minimal amount of triangles inside the geometry to compute.
Do you have data that highlights the performance impacts or why are you worried about it?
(2) This seems to collide with the general style of the game. I’m not saying you don’t have a legitimate request here, but from a design perspective it has very low priority and hence doesn’t seem like a good reason to request non qb file support.
(3) Regarding “stonehearth:proxy_model”, I have limited experience with that, so maybe someone else can jump in.
My considerably old machine experiences ~70% FPS drop when I build one of each Tier 1 Ascendancy blueprints and cover their roofs with roof tiles so it is a problem. After calculations I concluded I could reduce poly count by 85% if I used .obj instead of .qb with static animation. It’s also easier to make a non-voxel .obj from a .qb file than to animate it just for the sake of turning a matrix or two.
I tried many solutions and this would actually fit best because of its simplicity. I know it’s not 8-bit orthodox, it’s not even voxel art, but Archmod is planned as an unorthodox mod from its very beginning. For extremely detailed objects an obvious solution is using model scale lower than 0.1, I’ve tried 0.05 and while the level of detail was more than satisfying it didn’t look very Stonehearth-ish, not to mention the insane poly count. Scale 0.1 (left window) looks too detailed because of the voxelised diagonals, which also add a ton of unnecessary polygons, in this case 480, that is 120 surfaces per in-game tile as this window is 2x2.
.obj models were used at the beginning and they still work (try spawning stonehearth:proxy_model with debugtools’ Item Stamper). The thing is some .mtl files are present in stonehearth.smod and they were used at some point but I don’t know how to apply .mtl material to .obj model so the problem is actually .mtl material support, not .obj model support.
Zero attention is absolutely fine as all the objects I would use it with are completely static, the problem would occur if you decided to remove it (could that be called negative attention?).
As long as _radiant.client.create_obj_render_node() exists it should work properly.
My second thought is: weren’t .obj files fully supported in the past, prior to Qubicle? They must have had a proper renderer back then and a way to detect matching .mtl files (which point to correct texture map).
The only problem I have now is all .obj models are lacking textures, but they are not lacking material because they appear in the game. They respond to light changes (night, lamps) but don’t render a cursor entity model and aren’t transparent in ghost form. That’s not much of a problem because I need to keep .qb files anyway so I can use .qb for ghost entities and .obj for root (iconic works fine and scale from render_info is applied correctly).
Backwards compatibility is sometimes really hard to accomplish. And if an unnecessary feature takes extra time to maintain it sometimes is easier to just remove it. Hence I wouldn’t go down the path of using obj, considering it is now deprecated.
(1) I’m confused why the part that is hidden inside geometry by the animation causes so much performance use. Is it really that or rather the fact that the stone hearth engine doesn’t yet do a great job of merging big planes into few triangles for qb models? I’m honestly not sure where the qb import optimization logic is at. Probably had low priority over the world geometry optimization.
(2) + (3) You could go down the obj path here, but be prepared to rewrite at some point if it stops working.
Honestly, I would adjust the style to match the SH world and use the qb format. The performance concern is a legitimate request though.
If you are interested in some background information, meshing in Voxel Engines is an awesome topic that I wrote 3 blog posts on a while back:
@max99x: I’m assuming the world triangulation gets optimized, but the imported qb files do not? Is this something in the pipeline for engine optimization?
