[1.12] Obj Model As Block Problem

[KittenKoder]

 have search everywhere, and all the information I find is outdated, most of it so outdated that it actually says you need a custom loader for OBJ files still. But even the newest example that people often cite, the debug loader test on github, uses a bunch of deprecated methods and objects. So here's the problem, I can get the items to render correctly, but when I try to use an obj file for a block it only renders in the item form. When placed it renders nothing. I created a temporary custom renderer but all I can get is the two block tall block to render using only a small part of the texture. Like the coordinates for the block are being shrunk into a much smaller portion of the texture. 

 

So here's the Java class for the object:

public class MagitechStorageBinTall extends BlockContainer implements
		IMagitechBlock, ITileEntityProvider {
    protected String NAME = null;
    protected String MAGITECHID = null;

	public MagitechStorageBinTall(String unlocalizedName, String name, Material material, float hardness, float resistance, SoundType sound, int opacity, float lightlevel, String harvest, int harvestlevel) {
		super(material);
		this.NAME = name;
		this.MAGITECHID = unlocalizedName;
        this.setCreativeTab(CreativeTabs.BUILDING_BLOCKS);
        this.setHardness(hardness);
        this.setResistance(resistance);
        this.setSoundType(sound);
		this.setLightOpacity(opacity);
		this.setLightLevel(lightlevel);
		this.setHarvestLevel(harvest, harvestlevel);
		this.setRegistryName(Magitech.MODID, unlocalizedName);
		this.setUnlocalizedName(unlocalizedName);
	}

	
	@Override
	@Nullable
	public TileEntity createNewTileEntity(World worldIn, int meta) {
		return new MagitechTileEntityStorageBinTall();
	}
	
	@Override
	@Nullable
	public AxisAlignedBB getCollisionBoundingBox(IBlockState blockState, IBlockAccess worldIn, BlockPos pos)
    {
        return MagitechTileEntityStorageBinTall.BOUNDINGBOX;
    }
	
	@Override
	@SideOnly(Side.CLIENT)
	public BlockRenderLayer getBlockLayer()
	{
		return BlockRenderLayer.SOLID;
	}

	@Override
	public boolean isFullCube(IBlockState state) {
		return false;
	}
	
	@Override
    public boolean isOpaqueCube(IBlockState state)
    {
        return false;
    }
	
	@Override
	public String getMagitechName() {
		return this.NAME;
	}

	@Override
	public String getMagitechID() {
		return this.MAGITECHID;
	}

	@Override
	public Block getBlock() {
		return this;
	}

	@Override
	public void registerModel(ItemBlock item) {
		ModelResourceLocation itemModelResourceLocation = new ModelResourceLocation(Magitech.MODID + ":" + this.MAGITECHID, "normal");
		ModelLoader.setCustomModelResourceLocation(item, 0, itemModelResourceLocation);
	}

	@Override
	public void registerItemBlock(IForgeRegistry<Item> event) {
		final ItemBlock item = new ItemBlock(this.getBlock());
    	item.setRegistryName(Magitech.MODID, this.getMagitechID());
		event.register(item);
		RegistrationHandler.BLOCKS.add(item);
	}

	@Override
	public void registerBlock(Register<Block> event) {
		event.getRegistry().register(this);
	}
}

 

The JSON file:

{
 "forge_marker": 1,
 "defaults": {
 "textures": {
 "Material": "magitech:entity/storage_bin_tall"
 },
 "model": "magitech:storage_bin_tall.obj"
 },
 "variants": {
 "normal": [{
 }],
 "inventory": [{
 "transform": "forge:default-block"
 }]
 }
}

 

[Draco18s]

Problematic Code Issue #4

 

As for OBJ models, you still need to tell the game that you need an Obj Loader.

[KittenKoder]

Did you not read my post? I stated that the obj loading is working because it renders correctly when held in hand or inventory. The model is loaded, it is just not associating the texture with it as a block so it renders as "nothing." As for your #4 thing, this is a WIP class at this time and I am not progressing further into it if I cannot get the block to render correctly.

 

I repeat: The texture and model are loading, they are just not rendering in the world. When I apply the texture using a custom renderer, it appears as if the coordinates are scaled down.

 

The problem with most changes to Forge during this transition is the lack of documentation and Google's inability to fish this site's format as that post you linked never once came up in Google's listing.

[KittenKoder]

Another huge problem with the new methods is that it's not proper Java.

[KittenKoder]

Seeing as how I can't get the editor to work in this site, here is what I mean: 

 

[Draco18s]

Looks like it's rendering just fine. With the exception that the texture UVs are incorrect.

[KittenKoder]

  On 1/10/2018 at 4:47 AM, Draco18s said:

Looks like it's rendering just fine. With the exception that the texture UVs are incorrect.

Expand  

Exactly, but it uses a custom renderer that I pieced together by digging through Vanilla and old code, I can't find enough information on the methods to eve know if it's correct. Also I would prefer not to use the custom renderer.

 

public void render(MagitechTileEntityStorageBinTall te, double x, double y, double z, float partialTicks, int destroyStage, float alpha) {
		Tessellator tessellator = Tessellator.getInstance();
        BufferBuilder bufferbuilder = tessellator.getBuffer();
		
		BlockPos pos = te.getPos();
        IBlockAccess world = MinecraftForgeClient.getRegionRenderCache(te.getWorld(), pos);
        IBlockState state = world.getBlockState(pos);
        
//		bindTexture(TextureMap.LOCATION_MISSING_TEXTURE);
		bindTexture(TEXTURE);
		
		bufferbuilder.begin(7, DefaultVertexFormats.BLOCK);
		bufferbuilder.setTranslation((x - (double)pos.getX()) + 0.5, y - (double)pos.getY(), (z - (double)pos.getZ()) + 0.5);

		IBakedModel model = FMLClientHandler.instance().getClient().getBlockRendererDispatcher().getModelForState(state);
		FMLClientHandler.instance().getClient().getBlockRendererDispatcher().getBlockModelRenderer().renderModel(world, model, state, pos, bufferbuilder, false);

		bufferbuilder.setTranslation(0.0D, 0.0D, 0.0D);
        tessellator.draw();
	}

 

As you can see, it's a mess.

[Draco18s]

Whatever that is, you don't need it.

All you have to do to load obj models is this:

OBJLoader.INSTANCE.addDomain(Refrence.MOD_ID);

[KittenKoder]

  On 1/10/2018 at 5:11 AM, Draco18s said:

Whatever that is, you don't need it.

All you have to do to load obj models is this:

OBJLoader.INSTANCE.addDomain(Refrence.MOD_ID);

Expand  

Okay, are you not reading anything I posted or just the first few words? I do that, it loads the model, it even renders correctly in hand and in the inventory. But when placed it won't render at all without a custom renderer and even then the UV coordinates are wrong. My question is why and how do I fix it?

 

This is suppose to be a block you place, not something you carry, but when you PLACE it the rendering fails to function as expected. All model/block registering is done through the event system (which lacks in documentation and took a full day just to find the names of some classes for that) and the OBJ loader is made aware of the mod. The registering calls are all shown in the primary class, so what did I miss? What could cause the model to work correctly in hand and inventory but not when placed, as in PLACED AS A BLOCK.

[Draco18s]

  On 1/10/2018 at 5:20 AM, KittenKoder said:

PLACED AS A BLOCK.

Expand  

YES, I KNOW.

AND EVERY THREAD I'VE EVER READ HAS HAD TO DO NOTHING SPECIAL.

Except call addDomain. It uses the standard block json file and standard block model file, pointing towards the obj file.

That's it.

Nothing else.

[KittenKoder]

  On 1/10/2018 at 6:59 AM, Draco18s said:

YES, I KNOW.

AND EVERY THREAD I'VE EVER READ HAS HAD TO DO NOTHING SPECIAL.

Except call addDomain. It uses the standard block json file and standard block model file, pointing towards the obj file.

That's it.

Nothing else.

Expand  

That was done from the start, so it is not the problem. The model wouldn't load at all if that was not already done.

[KittenKoder]

Update: It appears that vanilla is still using the BlockContainer class and has a TESR attached to it. The entire reason interfaces were developed in Java was to prevent this mess of code that Forge and Minecraft are showing in 1.12. Ironic that the interfaces are being replaced with a system that will result in massive overhead and serious synchronization problems between Java objects, but hey, I don't plan to go past 1.12 ever anyway.

[Draco18s]

Oh. Looks like my first comment was the problem all along.

  On 1/10/2018 at 2:48 AM, Draco18s said:

Problematic Code Issue #4

Expand  

I think I'll take a few minutes of justified smugness.

[KittenKoder]

  On 1/10/2018 at 2:25 PM, diesieben07 said:

If you want a tile entity with Forge, override hasTileEntity and createTileEntity, which have been in Forge since forever. Do not use BlockContainer and ITileEntityProvider. They are messy vanilla code.

Expand  

I knew that part.  I was trying to see what the BlockContainer was doing to cause rendering to fail. I had to really dig through the code to figure it out though. The problem I am facing is that being new to modding for Minecraft while also being an old school Java developer, Minecraft is a total mess. Not to mention that the new capability system is not a Java convention, interfaces are still superior to such a thing because of native code implementations.

 

Essentially, before I get too far into the mod itself, I want to know what Minecraft and Forge do and how I can avoid the pitfalls that most modern mods seem to suffer. Since there is little documentation and no tutorials out there I have to drill deep for answers and just hope that someone else could help speed the process along. This particular issue had me baffled until I dug into the TESRs and discovered that the BlockContainer code somehow alters the model data.

 

I need to dig a bit deeper to know why it is being removed completely though, as opposed to having the flaws corrected or compatibility improved. My set of MagitechBlockPartial classes uses true Java conventions to accomplish much of what most of the Block subclasses in Minecraft do without all the mucking about with TESRs and using a minimal number of subclasses. My next goal is to understand what changed in the bounding boxes and how to use the stuff that's already implemented without too much headache. I'm all about reusing the code that's present versus making new stuff, but once in a while I am forced to just work from scratch, as was the case here.

 

  On 1/10/2018 at 4:52 PM, Draco18s said:

Oh. Looks like my first comment was the problem all along.

I think I'll take a few minutes of justified smugness.

Expand  

That did not help answer my question. 

[Draco18s]

  On 1/11/2018 at 6:11 AM, KittenKoder said:

That did not help answer my question. 

Expand  

If you'd followed the advice and stopped using BlockContainer your problem would have been fixed, by your own admission:

  On 1/10/2018 at 1:41 PM, KittenKoder said:

It appears that vanilla is still using the BlockContainer class and has a TESR attached to it.

Expand  

 

[KittenKoder]

  On 1/11/2018 at 6:28 AM, Draco18s said:

If you'd followed the advice and stopped using BlockContainer your problem would have been fixed, by your own admission:

 

Expand  

If you would read my posts you'd realize I didn't want to fix it, I knew how to do that already. I wanted to know why it was happening, I wanted to know the code that was causing it so I could avoid it in the future in case it effects things not yet mentioned by anyone else. The idea of fixing just one thing at a time without knowing why won't prevent future issues.

[Draco18s]

Ok, how about this:

BlockContainer fucks up everything. Not just rendering, it fucks up a bunch of other stuff too.

Has done since forever, that's why you aren't supposed to use it.

[Draco18s]

For reference, here's everything you said about your problem, all of which goes away when you stop using BlockContainer.

  On 1/10/2018 at 2:03 AM, KittenKoder said:

So here's the problem, I can get the items to render correctly, but when I try to use an obj file for a block it only renders in the item form. When placed it renders nothing.

Expand  

  On 1/10/2018 at 3:42 AM, KittenKoder said:

The model is loaded, it is just not associating the texture with it as a block so it renders as "nothing."

Expand  

  On 1/10/2018 at 3:42 AM, KittenKoder said:

this is a WIP class at this time and I am not progressing further into it if I cannot get the block to render correctly.

Expand  

 

Only here, after you solved the problem, did you even remotely tangentailly ask, why it happened:

  On 1/10/2018 at 5:20 AM, KittenKoder said:

so what did I miss? What could cause the model to work correctly in hand and inventory but not when placed, as in PLACED AS A BLOCK.

Expand  

What did you miss?

You used BlockContainer.

What would cause this issue?

Using BlockContainer.

[KittenKoder]

  On 1/11/2018 at 7:00 AM, Draco18s said:

For reference, here's everything you said about your problem, all of which goes away when you stop using BlockContainer.

 

Only here, after you solved the problem, did you even remotely tangentailly ask, why it happened:

What did you miss?

You used BlockContainer.

What would cause this issue?

Using BlockContainer.

Expand  

Why should be implied, should it not? How would you expect someone to learn what their actual mistake was if they don't know why? There are other classes that would cause the same problem, I have discovered these classes only because I figured out why BlockContainer was a bad class. I am developing this mod in the hopes of understanding how Minecraft functions, what makes it tick, so I can develop a game that doesn't make the same mistakes while utilizing concepts that work. Forge may be prematurely deprecating things, but it does correct some issues Minecraft has so knowing how it functions also helps. The mod is a happy side effect of my studies.

[Draco18s]

But you never asked why. You only kept asking "how do I fix this?"

And you kept yelling at me that I wasn't reading your posts.

But all you ever asked was "how do I fix it?"

And the answer was

Stop

Using

BlockContainer.

Done.

That's it.

Problem solved.

 

You want to know why BlockContainer fucks things up? Actually ASK. But you know what, good on you for digging into the vanilla code base and figuring it out on your own. Congradulations, you now know why we tell you not to use BlockContainer because it fucks everything up.

 

We solve problems for people, for free, all day long, every day of the week. We've seen the same problems so many god damn times Diebiesen07 made a god damn common problems thread.

 

And for reference, you're one "but you didn't answer my question" away from being added to my ignore list because I can't give any fewer shits any more. My first post in this thread solved your problem and all you've done since is bitch that I didn't tell you why it solved your problem without ever actually stating "what is it about the vanilla code that causes this to happen?"

 

And no, I'm not going to answer that question now either. Because I have no shits left to give. There's vanilla code for vanilla blocks like the chest, and it's crappy vanilla code that you should never use. End of story. You probably know more about it than I do, because I stopped using BlockContainer because it is garbage and didn't care to learn why. I learned the better way and moved on with my life.

[KittenKoder]

I asked what was wrong with using the class.

[KittenKoder]

I will confess that I am not use to socializing with humans, but I did not imply "no, your solution is wrong, go away". I needed the containers, which #4 does not explain ergo it did not help. The solution was to subclass the Container class so that there was less added code, thus reducing the amount of bloat to the mod.

 

Though the list is helpful, it does not offer much information as to what to do instead, much less how to avoid writing entirely new systems for doing things. Nothing personal, but it seems that Draco doesn't like to say much and that makes his advice less useful at times. Again, without explaining why or at least offering an explanation of what to do instead, no one else will learn anything. I am guessing that this is why the latest versions of Forge are often treated with disdain.

[Draco18s]

  On 1/11/2018 at 11:40 AM, KittenKoder said:

I needed the containers, which #4 does not explain ergo it did not help.

Expand  

BlockContainer does literally nothing useful for you. You think it does, but it does not.

Of all the things it "does" for you, only hasTileEntity and createTileEntity are things that you want. Forge has already made better versions of these methods (states instead of metadata integers!) available in the Block class.

 

There.

Is.

Nothing.

Else.

You want from this class. You extended it without knowing what it did, assuming that it was full of magic and candy without actually looking. You blindly said "I want a block that holds items, therefore it is a "container" I am going to use BlockContainer because it obviously does those things" when it does not. Items are stored in the tile entity, not the block and the only important thing for tile entities is hasTileEntity and createTileEntity which you can get from the Block class. Every thing else that class does is detrimental to your code and causes one problem or another.

  On 1/11/2018 at 11:40 AM, KittenKoder said:

I am guessing that this is why the latest versions of Forge are often treated with disdain.

Expand  

No, they aren't. People "have disdain" for the newer versions of Forge because it's for newer versions of Minecraft, and there's a large section of the community that thinks that 1.7.10 was the "bestest version ever" of Minecraft because of the combat changes added in 1.9/1.10.  Forge for 1.10+ is amazing. Capabilities are the most awesome system that Forge has ever added to a modder's toolbox, increasing inter-mod compatibility massively.

 

Now, all that said (I'm late for work),

  On 1/11/2018 at 11:40 AM, KittenKoder said:

Nothing personal, but it seems that Draco doesn't like to say much and that makes his advice less useful at times.

Expand  

For a problem that has occurred hundreds of times, there's no point. You want to know more? Search the forums.

How many times should I have to explain the innermost workings of a problem to a new modder? Ten of you join the forums every day.

And the thing is, of those ten, nine point nine of them want anything more than "solve my problem" or "give me teh codez." You never asked for anything more, so how was I supposed to know you needed more?

 

So. Welcome to my ignore list, as obviously you won't be interested in anything I have to say, so why should I be interested in what you have to say?

 

[MegaTigerpaw]

  On 1/10/2018 at 4:47 AM, Draco18s said:

Looks like it's rendering just fine. With the exception that the texture UVs are incorrect.

Expand  

"custom": { "flip-v": true },

[Luis_ST]

1.12 is no longer supported on this forum.
Please update to a modern version of Minecraft to receive support.