[1.12] Tile Entities made from .obj files that are bigger than 1x1 block

[ConfusedMerlin]

Good evening,

 

as you might know, I've prepared some pictures again. Okay, its just the first picture, because I found something inside my own blocks that does help to visualize the problem in better way than the vanilla block I had in mind.That cyan block comes close to to beeing batsh!t crazy stuffed with (unnecessary) settings, but he is great for visualization. Also note that its bounding box is a tight bit smaller than these of usual blocks, but it does disappear inside the... objects bounding box, while still covering its upper half. 

So, what do we see there? Its... a rocket. Yes, I know, I must put a label on it because it does look rather stupid, but its surprisingly hard to do the low-poly modelling needed for minecraft; the first draft had maybe more vertices than the visible world in my game, but... another topic for another day. 

 

But, as on might have observed by now, something is wrong with it. This rocket-like thing does originate from Blender, so its a 3d model exported as an .obj file (with its .mtl file too) and except for some less visual pleasing edges everything is alright with its appearance. But it does have a problem: it takes double the height of a usual block.

To enable it doing some more interesting stuff later on I had to make a Tile-Entity out of it, and while its still unhappy with the missing pieces of code needed to save its current state, minecraft seems to be rather happy with it. (forge less....). Oh, if this is of any importance, I used the hasTileEntity() and createTileEntity() functions as advised somewhere in this forum instead of the old methods you might find in older threads about this topic. It... seems to work well this way.  

 

But (!) by accident I had once a piece of building material attached to a block which was located next to the upperhalf... and it did cover the upper half completely. 

 

First I was like "oh dumb me I need to adjest the bounding box", so I went out and adjusted the AABB to fit the dimensions of that rocket. That fixed the player walking though the upper half, but not being able to place blocks that will cover up the upper half. I asked the internet for help, which replied "use multiple blocks" and "take an example for this looking at the vanilla bed and door". That did sound promising, but I soon realized two things:

I'm not able to spot the piece of code who does handle the placement of the second part after all.

Everything they do in their examples and vanilla code is done with json Models. Even the tile entity parent they used in their json model files seems to be unavailable for me. 

 

So... I started wondering and asked myself "how do mods like immersive engineering do this?". I remembered another mod... Waystones.... which does use objects of a (kind of) similar shape (you guessed it - its waystone). And it does have a github and is pretty small, so it wasn't as confusing as other sources. It took some time, but I thought I found the piece of code responsible for handling the double block creation (the "onBlockPlacedBy" Method). So I tried to recreate what was done in the Waystone-Mod, but ended up with... well... the second picture. It does have its charm, because it does look like a proper multi stage rocket, but after all this is supposed to be a solid booster science package delivery vessel (or a "sounding rocket", if you are interested in that kind of stuff). So the second half isn't needed. 

The guy who does provide waystones source did left out his models (or I didn't find them), so I could not take a peek to find out what his model(s) are made of, but after I didn't find a .obj in the pathes names, I think he is using .json too. So this approach wasn't as successful as I did hope for. 

 

*sigh* I do hope that I don't need to create .obj models which have been separated into block sized chunks to have them appear in the game correctly. You know, there is a... quite big multi block structure awaiting further success in modding, which would be a giant pain to cut in parts. 

I do hope there is another way to get this done. 

 

So, to condense my writing to a proper question: What needs to be done to have this two block high obj model appear correcty when placed? 

If I might put in a guess, I think it will boil down to have all the area which isn't the place the tile entity was put to ground in the beginning get covered with invisible dummy blocks. If that's the way it needs to be done, then whats the proper way to represent this inside the code? Please do not just point out to Bed and Door, because I already failed to find the place in the code where this happens. Its all about foot and head halves or upper and lover halves and how they interact, but where by all enderpearls does the creation happen?

 

confused Greetings, 

Confused Merlin

[larsgerrits]

Override TileEntity#getRenderBoundingBox to return an AxisAlignedBB which corresponds to the size of your model.

[ConfusedMerlin]

9 minutes ago, larsgerrits said:

Override TileEntity#getRenderBoundingBox to return an AxisAlignedBB which corresponds to the size of your model.

 

Lets see....I tried getting the AABB from the block class using the constructor (same error as before), and tried to designate it manually inside the tileentity class (same error) aaaand... using the way it had been done inside the waystone mod (return new AxisAlignedBB(pos.getX(), pos.getY(), pos.getZ(), pos.getX() + 1, pos.getY() + 2, pos.getZ() + 1);)

 

Same effect sadly  The upper half can be covered with blocks put sideways to walls; the bounding box still does look the same as before, but I guess there isn't anything that should change after all. 

 

By the way, I cannot interact with the upper half, expect for walking over it in a correct manner. 

Edited July 9, 2017 by ConfusedMerlin

[larsgerrits]

I misunderstood your question, I thought you were having a problem with rendering OBJ models bigger than 1x1x1. My bad.

 

But yes, you do need to use 2 or more blocks for that. The bed item places its blocks in ItemBed#onItemUse.

[Draco18s]

Bounding boxes, collision boxes, and so on should be limited to 1x1x1 blocks. No more, ever.

Trying to make it larger will lead to weird side effects, like mobs trying to jump over it, but unable to because it's too tall, but pathfinding says that there's only a 1x1x1 block there, so it's fine.

(You remember mobs trying to jump over fences? Yeah. That).

[ConfusedMerlin]

Gooood Evening,

 

It was kind of an odyssey  sometimes, but I got that multiblock-stuff done. Part of. 

 

I removed the bigger-than-1 bounding boxes and (damn it, why didn't I got the idea to look there by myself in the first place? ) tried to recreate what happens inside ItemDoor's methods. It's not as fool-proof as the vanilla methods, but it does provice the actual model and the invisible multiblock to claim the space above.

Yeah, another picture  Well, it isn't as transparent as it will be one day, but I think switching the texture once all fits will be the most minor task on my list. 

Oh, I do wonder one thing - if its so important to keep the collision boxes this small, wouldn't it be useful to have forge throw one of its "this is bug, contact the author" messages if one of these appears? After all, there are sure others out there who will went the same way as I did because they are unaware of the problems the big collision box does create.... 

 

And I think one of the more important lessons learned was that the minecraft world as forge does see it does not consists of blocks, but of positions with IBlockStates  that get a given state out of the registered blocks list. 

By the way, I was about to start yelling at the general direction of my PC because I didn't found the way of choice to get a block not available during the onItemUse Call (like my multiblock), but after trying adventurous  ways of getting it from several registries (don't... ask, seriously), I had a bright moment and found a static Method inside Block.class (Block.getBlockFromName) that will provide the Block I want if I offer it the "modid:blockname" String. *sigh* 

Is this the recommend way to do this? 

 

Some other things restrain putting the "solved" Tag to my topic. I do wonder where I should keep the information about the quite important question "what locations in that world do belong to what multiblock-structure"?

I do have a small container class ready for use, but right now I didn't found the place where it should belong to. That class is just an ArrayList with all positions that belong to the multiblock - plan is to have the IBlockState at a given location holding a reference to that Container, which will use its destroy method to turn all its other mutliblocks to Air if one of the multiblock-blocks get destroyed somehow. 

 

Or to put it more simple: When I leftklick the bottom of the rocket, the transparent "multiblock" still remains, and via versa. I'm aware that I have to connect the two places to destroy the other one by myself, but I wonder what would be a good location (class-wise) to store the informations.

Vanilla Beds and Doors just get their location, their rotation and their part (upper and lower or head and foot) and figure out where the other one should be (which works usually). I hope I can store all the mutliblocks belonging to one structure somewhere... which will be incredible handy if I once tackle huge multi block structures. 

 

Curious Greetings, 

 

Confused Merlin