1.19 blocks not being rendered #2046
Comments
|
I haven't added any 1.19 blocks yet, so this is expected |
|
Ah I see. Thanks for the info. I checked the 1.19.jar textures file and it seemed larger than 1.18.2.jar so I assumed it had the new blocks inside. Is there a way I could receive a notification when the 1.19 blocks have been added? I may wait until that happens before adding the render to a cron job. Cheers. |
|
If you have e-mail notifications on github enabled, you will get one when I close this issue or someone comments on it. |
|
ah of course! well that's fine then. 😁 is there anything i might be able to help with in regards to getting the new textures into the 1.19 jar file? |
|
To get the list of missing blocks, I added this to world.py def _get_block(self, palette_entry):
if ( palette_entry['Name'] not in self._blockmap):
print (palette_entry['Name'] + "\n")The filtered output, when I render my testworld, delivered this missing blocks:
Btw, this old blocks also showed up
Is this list complete or are there more new blocks? |
|
Missing frog related blocks
|
|
Commenting for email notification - thx everyone who is working on this. |
|
Is anyone working on this? If not, I'm happy to give it a go. I'm not a Python dev (primarily PHP) but i've done a bit and it seems that this might not be a hugely taxing task? |
Current overviewer covers 87% of blocks from 1.19 (117 blocks missing from a total of 933).
|
|
Is it that the textures are in the .jar file but the code needs updating to handle each new block? Or do the textures need adding to the .jar file so the code can access them? Or both? 😆 |
|
@BenKennish Every block needs to be added to the code individually in multiple places. For simple blocks this is relatively easy, for blocks with complicated models this is a lot of work. But the code is pretty straight forward and Pillow is pretty good at reviewing, so you could give it a try. |
|
I added mud, packed mud, mud bricks, mud brick slabs, mangrove leaves, mangrove roots, mangrove logs and stripped mangrove logs. I still hate spending time on this because it's something that wouldn't need time invested if someone were to rewrite Overviewer to actually do block models, but I guess bandaid fixes is all I have the motivation for. |
|
Rewritten overviewer to do rudimentary block model reading; #2054 |
|
Any progress on this? Looking at the above from lieuwestra it seems like he had a more in-depth fix, but it seems to still be pending a merge? (Not very proficient at Git so i'm unsure) |
|
@lieuwestra |
|
@IncredibleHolg fixed |
|
Hi, E Could not render chunk 62,22 for some reason. This is likely a render primitive option error
E Full error was:
Traceback (most recent call last):
File "./overviewer_core/tileset.py", line 1105, in _render_rendertile
c_overviewer.render_loop(
File "./overviewer_core/world.py", line 1930, in get_chunk
retval = super(CachedRegionSet, self).get_chunk(x,z)
File "./overviewer_core/world.py", line 1743, in get_chunk
return self._r.get_chunk(x,z)
File "./overviewer_core/world.py", line 1604, in get_chunk
(blocks, data) = self._get_blockdata_v113(section, longarray_unpacker)
File "./overviewer_core/world.py", line 1399, in _get_blockdata_v113
translated_blocks[i], translated_data[i] = self._get_block(key)
File "./overviewer_core/world.py", line 1079, in _get_block
axis = palette_entry['Properties']['axis']
KeyError: 'axis'looks like chunks in 1.13 format. I will try to narrow down the source. |
|
@IncredibleHolg There might be hay bales without the axis property. I've fixed it by using a default values if the axis is missing. Should work now. |
|
Hi @lieuwestra, The actual render finishes now without any error. This is the error that occurred:
multiprocessing.pool.RemoteTraceback:
"""
Traceback (most recent call last):
File "/usr/lib/python3.8/multiprocessing/pool.py", line 125, in worker
result = (True, func(*args, **kwds))
File "/usr/lib/python3.8/multiprocessing/pool.py", line 48, in mapstar
return list(map(*args))
File "./Minecraft-Overviewer/overviewer_core/aux_files/genPOI.py", line 132, in parseBucketChunks
data = rset.get_chunk(b[0], b[1])
File "./Minecraft-Overviewer/overviewer_core/world.py", line 1605, in get_chunk
(blocks, data) = self._get_blockdata_v118(section, longarray_unpacker)
File "./Minecraft-Overviewer/overviewer_core/world.py", line 1375, in _get_blockdata_v118
translated_blocks[i], translated_data[i] = self._get_block(key)
File "./Minecraft-Overviewer/overviewer_core/world.py", line 1020, in _get_block
(block, data) = modelblocks[slab_to_double[key]]
KeyError: 'minecraft:smooth_stone'
"""
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "./Minecraft-Overviewer/overviewer.py", line 653, in <module>
ret = main()
File "./Minecraft-Overviewer/overviewer.py", line 168, in main
g.genPOI.main()
File "./Minecraft-Overviewer/overviewer_core/aux_files/genPOI.py", line 589, in main
handleEntities(rset, config, args.config, rset_filters, markers)
File "./Minecraft-Overviewer/overviewer_core/aux_files/genPOI.py", line 218, in handleEntities
results = pool.map(parseBucketChunks, ((buck, rset, filters) for buck in buckets))
File "/usr/lib/python3.8/multiprocessing/pool.py", line 364, in map
return self._map_async(func, iterable, mapstar, chunksize).get()
File "/usr/lib/python3.8/multiprocessing/pool.py", line 771, in get
raise self._value
KeyError: 'minecraft:smooth_stone'Looks like this is an unconverted 1.18 region. The POI function searches for banners, no clue why smooth_stone is an issue global json
import json
def bannerFilter(poi):
if poi['id'] == 'minecraft:banner':
if 'CustomName' in poi.keys():
cnstring = poi['CustomName']
print (cnstring)
cname = json.loads(cnstring)
if 'text' in cname.keys():
print(cname['text'])
print(poi)
return (cname['text'])
renders["render1"] = {
'world': 'Nitrado vanilla',
'title': 'Nitrado Vanilla',
'markers': [dict(name="Banner", filterFunction=bannerFilter, icon="markers/marker_town.png" )]
} |
|
@IncredibleHolg good to know the regular render is fine now. Are all expected blocks rendering properly? |
|
Are these fixes being applied to the master branch? Could I consider this branch as "generally" stable and do a git pull before each daily render of my world or do you think that would be unwise? |
|
This is still in the state of a pull request and not is the master branch. If you want to test it, you can follow this instruction on devopscube.com More testing will be helpful to get this merged into master. |
|
Just to be clear, this is the system that will read blocks dynamically and insert them into the code automatically right? So there is no longer a manual need to insert blocks in the future? |
|
Depends on the block. But full block textures will be automated. |
|
@BenKennish You can use it and it won't irretrievable corrupt your render and I will keep it up to date with the main branch, but will probably go through a less stable phase if I can ever get some commitment from @CounterPillow to do a proper review. They can still decide dynamic rendering will never go to main. It would be a big help if you do run it and report any errors back on de pull request. Identifying bugs now helps get this to the main branch quicker. Also I won't update the C rebuild trigger every commit so if you don't explicitly rebuild the c code in your daily update script this might still break between commits. |
|
@lieuwestra |
I tried to follow the guide but didn't know what the name of the branch was that I needed to use so I assumed master but it failed.. |
|
I believe you have to add my repository to your remotes first, and then checkout the branch; |
|
@BenKennish git fetch original pull/2054/head:genericblockmodels
git checkout genericblockmodels |
|
Ah that's great. You typed |
|
However I cannot now pull with I tried |
|
@BenKennish $ git clone https://github.com/overviewer/Minecraft-Overviewer
Cloning into 'Minecraft-Overviewer'...
$ cd Minecraft-Overviewer/
$ git fetch origin pull/2054/head:genericblockmodels
remote: Enumerating objects: 167, done.
remote: Counting objects: 100% (167/167), done.
remote: Compressing objects: 100% (58/58), done.
remote: Total 167 (delta 118), reused 155 (delta 109), pack-reused 0
Receiving objects: 100% (167/167), 170.92 KiB | 2.16 MiB/s, done.
Resolving deltas: 100% (118/118), completed with 4 local objects.
From https://github.com/overviewer/Minecraft-Overviewer
* [new ref] refs/pull/2054/head -> genericblockmodels
$ git checkout genericblockmodels
Switched to branch 'genericblockmodels'As @lieuwestra mentioned, you may add his working clone, if you want to follow his changes. $ git remote add lieuwestra https://github.com/lieuwestra/Minecraft-Overviewer.git
$ git fetch --all
Fetching origin
Fetching lieuwestra
remote: Enumerating objects: 70, done.
remote: Counting objects: 100% (70/70), done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 70 (delta 53), reused 60 (delta 50), pack-reused 0
Unpacking objects: 100% (70/70), 46.21 KiB | 666.00 KiB/s, done.
From https://github.com/lieuwestra/Minecraft-Overviewer
* [new branch] complex_blocks -> lieuwestra/complex_blocks
* [new branch] master -> lieuwestra/master
* [new branch] read_models -> lieuwestra/read_models
$ git checkout read_models
Branch 'read_models' set up to track remote branch 'read_models' from 'lieuwestra'.
Switched to a new branch 'read_models'On an additional branch, you can use |
|
Ah sorry @lieuwestra I missed your post somehow. Yeah that's great. I've done that now and will keep pulling and using the |
|
@lieuwestra I did find two issues that I wanted to report here. It seems that your update produces the incorrect block orientation for mushroom blocks and log blocks. Here are before/after comparisons for each of those two issues. Notice the oak logs on the front of the barn, first (correct) in 0.19.6 and second (incorrect) after your update: And in this pair of images, notice the change in the mushrooms, first is 0.19.6 and second is after your update: Thanks again. I hope this helps. I'm happy to retest if/when another update is available. |
|
@capnbfg Also, won't your barn burn down with lightning rods on wood? |
|
Thank you @lieuwestra, much appreciated. It didn't occur to me to mention it before, but you are correct, my render did use northdirection upper-right. Good question about the lightning rods. It hasn't caused any fire yet. If the Minecraft wiki page is correct, the ignition area is a 5x5 horizontal space centered on the lightning rod. Since these lightning rods are above all the wood it shouldn't be an issue. |
|
@lieuwestra |
|
@IncredibleHolg very possibly. I thought I'd tested it after switching the to master/main branch too though, but I've just done that and run a render and got.. |
|
@BenKennish BRANCH=master
git checkout $BRANCH && python3 setup.py build |
|
Aha! So I had forgotten to do this. However, this gave me an error with an include(?) statement or something like that but then I remembered that I'm using Rocky Linux 8.7 (previously using CentOS 8) and I needed to compile with some flags to include some python-pillow stuff.. and this worked and the world render completed. Of course, the render is now missing all the 1.19 blocks that were previously working when I was using @lieuwestra 's fork, but hopefully either that can be fixed or that work can be merged into the main project. Thanks, |
|
I've since found that I can avoid the python-pillow source extraction stuff on Rocky Linux 8.7 by installing the |
|
Is the Overviewer project itself dead? I opened this issue in June last year and the new blocks are still not supported. The latest news post on the website (https://overviewer.org/) says "Overviewer 0.15 is out, supporting Minecraft 1.15 by CounterPillow on Dec. 27, 2019" Don't get me wrong - I do appreciate the work that goes into projects like this but if the code is not really being maintained, I will try to look elsewhere for a similar solution. Cheers. |
|
yes, Overviewer is no longer being maintained |
|
ok thanks 👍 it's a shame because it's a great piece of software but i'm sure there are good reasons 🙂 |
Would you mind share more about that ? I've spent the last few day setting up Overviewer, just to stumble on your comment. |
no
no, the website and repository will remain accessible as-is.
Sure, I'll put a note in the README. |
|
The main README states ..
Instead please use the new working (“successor”) version of Overviewer supporting 1.20 worlds and textures. |
|
Yep, can confirm, most of the new blocks from 1.19 and 1.20 have been added and are working. |
Just finished rendering a 1.19 map using Minecraft Overviewer 0.17.63 (97ef871) but the blocks new to 1.19 do not seem to be being rendered. I downloaded the textures from https://overviewer.org/textures/1.19 into ~/.minecraft/versions/1.19.jar before starting the render.
The render process did not throw up any warnings or errors except for some:
"W Unable to get player name for UUID" which are caused by our server using the Bedrock->Java proxy called Geyser - another issue I need to sort out sometime.
Here's a screenshot of the latest render...
The 3 torches in a line just below the "white arrow on orange" marker thing are supposed to be on top of mud brick blocks and there is also a mud brick slab and mud brick steps close by that should be visible. I'm not sure what the block that looks like a block enclosed by wooden fence panels is supposed to be but I think it's the skulk catalyst that I had there. Also the black spaces I think should be skulk blocks.
Thanks in advance for any help :)
The text was updated successfully, but these errors were encountered: