jmy1000 / cyclesmineways Goto Github PK

Probably an easy fix, I'll look into it

When I was making USER_INPUT_SCENE respect scenes, I was on blender render (not cycles) on another scene (that the script shouldn't have touched), with another cycles scene with a mineways .obj in. After I ran the script, Blender would crash if I used the rendered view port in the blender render scene (instant shutdown, not a freeze).

I have a feeling it's either due to the script still accessing things it shouldn't, or an internal Blender problem.

How to recreate the problem:
download this .blend https://www.mediafire.com/?347evt90fsnfskl
be on Scene.001
load in script and change USER_INPUT_SCENE from [] to ["Scene"]
run the script
change the view port to rendered mode

The options that the user can modify are currently in the script, this means it's easy for the user to not know that there are customisable features about the script (as what happened with @Masonrf).

One quick solution might be to have a popup display when the script is ran saying that it is customisable, though this will likely be annoying to a regular user, and they might not notice a new setting added to the script.

Another way of doing it is having the script create buttons. The user can then use these buttons to configure the script. Due to the buttons being in front of the user, it's unlikely they will not know about a feature.
After they have configured the script using these buttons, they can then press the "run script" button which will run the script.
This method has the advantage that all the options are given to the user, without them needing to know how to modify the script. It may also make it easier for the user, for example, tick boxes could be used to change USER_INPUT_SCENE.
This method of user interaction might be annoying, though. Because the Blender GUI is so cluttered with other stuff, and the user has full control over their own GUI, it's hard to find a menu to latch onto that the user will find easily (I recommend adding another tab to the left side of the viewports windows (along side "tools", "create", ect))

I've already created some GUI code, so it shouldn't be too hard to copy and paste that for other uses.

Minecraft 1.9 was released yesterday. Although Mineways doesn't yet support it, preparations need to be made for it.

From a user of Mineways: Blender is a powerful 3D Renderer as you know it and the new 2.80 versions with upcoming new features is approaching. What does concern Mineways world importing is working perfectly, however the CyclesMineways script (and I tried the both versions) doesn't work anymore.

I use this script rather often when rendering Minecraft worlds and I have noticed a few lighting issues with the current CyclesMineways script:
I am using Blender 2.77 and CyclesMineways 1.2.2:

Without editing any of the blocks's nodes, the blocks that have light emit light like they should, but the blocks themselves are very dark (which looks kind of crappy):

Editing the "Emission" node and setting the strength to about 20 Seems to give a much better looking result:

Another thing I noticed were that some non-block emitters do not emit light like the blocks do (as seen in above images). I'm uncertain of a way to fix this, but there is a large difference in the nodes of light emitting blocks and light emitting (or supposed to be at least). The emission strength node that I changed is circled in the below pictures. This is what I was suggesting needed to be changed in the above section.
Difference between Glowstone and Torches:

I'm not sure if any of these things are able to be put into the script or if I just have to do it manually. Any kind of feedback would be appreciated!
Thanks,

• Masonrf

See https://www.minecraftforum.net/forums/minecraft-java-edition/discussion/326119-mineways-3d-prints-of-minecraft-objects?page=22

ZaffreAqua writes:

 the Cycles script under the documentation section of the site would appear to be outdated and/or defunct

and recommends:

https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-tools/2840563-blender-mineways-worlds-in-cycles-render

Should I update to point users at this resource?

Title. Leftover from shader change of the emission shader.

Seems like the best way of handling block properties is class based. This issue is dedicated to the discussion of this issue.

Minecraft 1.10 "Frostburn Update" was released two days ago. Mineways 5.01 has been released, which includes support for Minecraft 1.10 and other features. Accommodations need to be made for these

This includes:

• Support for new blocks
  • Structure void
  • Magma block
  • Nether wart block
  • Red nether brick
  • Bone block
• Support for changes to previously existing blocks
  • New bounding box for rails
  • Stained clay blocks being renamed
• Support for blocks that previously didn't work in Mineways
  • Tripwire hooks
  • Redstone wire states

Currently there's not really a great system for checking to see if any given material is related to Mineways or something else that just exists in the scene. Adding some form of checks to help with that beyond what exists would be good.

Mineways v5.04 made a lot of changes to how blocks are handled. Due to the way that CyclesMineways looks for strings to identify the proper shader, a lot of shaders got broken.

It's been a while since we have updated the master branch, so I think we should release a version update.

I think we should bug test, fix any small bugs, and add small features now and then release update 1.2.4.

Any thoughts/suggestions?