[1.10.2] Rotate block-model by small degrees -without- TESR?

[Matryoshika]

I've been coding a couple of "utility" blocks (speeds furnaces, picks up stuff, places stuff, etc). They all look the same (.obj models FYI, with only difference being the colour).

I want to change their yaw, that is, make them rotate around the y-axis, very slowly. That is all I want these to do.

However, I do not see TESR rendering being an option at all, due to the amount of different blocks, each with their own functionality. A player just near a couple of these (7-, will see a notable decrease in FPS.

 

So, I'm asking this: Is there an option available to render these models, that fills these requirements?

1) Less overhead compared to standard TESR.

2) Gives access (direct or hell, even with reflection if needed) to rotating the model around at least the y-axis.

3) Easily implementable for several different blocks. (For example, being required to pass the type, brings issues with long list of copy/paste'd code with only difference being the passed type, every 20 lines.)

 

I have already tested Forge's own CapabilityAnimation to render these, but that very quickly becomes extremely bulky when being implemented for several blocks. The added requirement of having a block, tile AND an entity, for each damned model... just no. Please spare me. The damned ClientProxy (or the class being initialized FROM it, would be ~amount of blocks*30 lines long. With 5 already made, another 10 planned, and who knows in the future, that'd be a ridiculous copy/paste'd wall of text)

 

If I'm out of luck, and nothing like this exists, I'm thinking of simply removing the TileEntity code, and have the block place down a proper Entity instead, which does the same thing that the TileEntity did, of which I can have it's onUpdate() simply edit the yaw by a degree every ~2-3 seconds. Would there be any significant drawbacks from this?

[KeeganDeathman]

In your block class, declare a property int called angle

In your tile entity, extend ITickable, and add to angle(or reset) when needed

In your blockstate, {"model":"whatever","y":angle}

[Matryoshika]

I'm talking about 1 degree every ~2 seconds.

I thought the blockstate was locked at multiples of 90? (or was that 22.5?)

 

If this is that easy, I'm going to cry...

[KeeganDeathman]

I'm unsure. If it does support that in depth, you should be good, although I'd use #scheduleBlockUpdate in stead of #update

[Leviathan143]

I'm talking about 1 degree every ~2 seconds.

I thought the blockstate was locked at multiples of 90? (or was that 22.5?)

 

If this is that easy, I'm going to cry...

 

Blockstates only allow rotating models in increments of 90 degrees. Item/block models allow individual elements to be rotated in increments on 22.5 degrees.

[Matryoshika]

So I'm taking it that using an Entity instead of TileEntity is the only viable option for animation without the overhead, and with sane amounts of code per implementation?

All this trouble for rotating the yaw of the model =_=

[larsgerrits]

Have you actually tried a TESR? Only a few of those around shouldn't impact your FPS a lot.

[Matryoshika]

Have you actually tried a TESR? Only a few of those around shouldn't impact your FPS a lot.

I did.

I got 5 Utility blocks. These are meant to do specific tasks, like picking up EntityItems, from example the (internally named) CropGrower that grows and harvests pretty much anything that implements IGrowable, and more (stems, sugarcane etc), or reversely, the blockplacer that places EntityItems if possible. My point is: These are meant to be commonly used blocks for setups in your base!

I was testing with 8 of the CropGrowers, and my FPS dropped by a considerate amount! Still above 60, but the point is made. I do not want to create a renderer that will be shared by many (5 made, 10 more planned, who knows after that) blocks, which can make the game unplayable for people who are unlucky enough to have bad computers!

 

As far as I've read, TESR's do not bake the model, hence why they are lacking in optimization.

Of course, you can get a baked model and render it after translating it, using

Minecraft::renderModel

in the

renderTileEntityAt

method, however, damage is still done, as the TESR is made to scrap and re-draw every damned frame.

The model itself is a floating crystal. Translucent. About 85% alpha. It also needs to spin. Apart from the translation, there also needs to be GLxx calls to enable blend, do blend, rotate, and after rendering, undo these (blend is needed as I cannot seem to replicate the behaviour of

BlockRenderLayer.TRANSLUCENT

).

Translate + enableBlend + blend + rotate + undo blend + undo rotate + disableBlend = 7 calls to GLxx. That's far from a simple baked model.

 

[TheGreyGhost]

Hi

 

Block models will never work for that type of animation because they aren't updated every frame.  They are compiled once into a render list or vertex buffer and not refreshed unless the blocks are modified (created, destroyed, blockstate changed, etc).

 

You can animate the texture but that's it.

 

I think a TESR is your best option.  If it's causing a massive slowdown it's almost certainly because you've implemented it inefficiently, or perhaps your model is too complicated (too many quads).  If you compile your quads to a vertex buffer, cache it, and draw that in your TESR, it will be just as fast as drawing block models, maybe faster.

 

-TGG

[Matryoshika]

@TGG

Thank you.

Yes, I know the model of the block cannot be "animated" however, you can -use- that model TO animate.

[spoiler=Example]

Example code: https://github.com/Matryoshika/Underworld/blob/master/src/main/java/se/Matryoshika/Underworld/Content/Rendering/TERenderEnderPortal.java

Example image:

 

 

 

The code inside the spoiler is what I have been using mostly, to render special blocks and TESR's, however, for very common blocks, the overhead would have been too much for my liking, thus why I made this thread.

However, I've hit a wall that sadly means I need to give up the rotational aspect of the blocks. While I can render the .obj-models, they render without any visible edges in the model. Think of a monotone colored model, where the edges blend together too well.

However, you did manage to teach me how to optimize my TESR's, for which I am quite thankful for.

The blocks will be too dull as just blocks, so I will keep the TESR's, just have them work in tandem with the actual block-model.

 

[TheGreyGhost]

Hi

 

However, I've hit a wall that sadly means I need to give up the rotational aspect of the blocks. While I can render the .obj-models, they render without any visible edges in the model. Think of a monotone colored model, where the edges blend together too well.

Yeah that is a problem if you don't use lighting.  The vanilla blocks use a manual lighting method for faces which point east, north, etc.  Vanilla items use a couple of openGL light sources.  So you could try turning on the item lighting which might make your edges show up better.  Alternatively you could change some of the quad textures to be a bit brighter or duller.

A bit more info here...

http://greyminecraftcoder.blogspot.com/2014/12/lighting-18.html

 

However, you did manage to teach me how to optimize my TESR's, for which I am quite thankful for.

The blocks will be too dull as just blocks, so I will keep the TESR's, just have them work in tandem with the actual block-model.

I've used that before and it can work really well; the block model part blends nicely with the scenery and the animated bit is easy to render separately.

I've put an example of something like that in this tutorial project:

https://github.com/TheGreyGhost/MinecraftByExample

(see MBE21)

 

-TGG

 

[jabelar]

I kinda liked your idea of using a regular entity for this. Control and coding would be really easy, and frequent updates and lighting would work well.