Feature Requests

= Will be fixed implemented next release

= Feature has been released

Reflection
Perhaps a feature could be implemented that controls the amount of reflection water gives. That would be especially great when you use big waterworlds which then could reflect the sky map at the end

Preview Window Separated in OS x
I can't have the preview window in a separate "Space"(10.6.8), or "Desktop"(10.7+) from the render controls. This means I have to keep moving/resizing the preview window in order to see how a control affects it. Other apps such as Firefox let you move windows from place to place, but Chunky groups them together.

Custom Cardinal Directions
A while ago (official release) the cardinal directions of minecraft changed. On my server the directions are still defined by the sun's old path meaning negative x is north, not z. Would it be possible to change solar north within chunky to correct this when rendering?

Edit: just found that the yawn and pitch of the sun are manually customized, however showing their values in editable text would be useful so the same values can be used for a later rendering

//Eneroth3

Scene Loading
Add button to load scene directly from the main window /Jesper Öqvist (talk) 12:18, 13 July 2012 (UTC)

3D Preview
Maybe you could make a window which shows what the chunk is going to look like but not in the best picture quality.
 * Unsure what you mean. The 3D view works that way already, when not rendering (path tracing) it shows a preview that was quickly ray traced. /Jesper Öqvist (talk) 00:06, 31 May 2012 (UTC)
 * I think what the user above wants is a rough and fast image of what the picture he is rendering looks like. I think this would be useful in determining how the shadows fall while using the yaw and pitch of the sun instead of it continually starting over and waiting a second or two to see the shadows. It saves a little bit of time. Also if you add a model sphere in the sky so we could visibly see where the shadows will be casted would also be very useful feature.
 * I've been wanting to add a slider or similar to the Render Controls dialog that lets the user customize ray depth. This could probably be used for rendering an improved preview. /Jesper Öqvist (talk) 09:17, 1 June 2012 (UTC)
 * To test my lighting settings, I just shrink the canvas size to about 1% of the final result. Then I can turn on rendering and play with sliders and camera settings live, with a rough preview.  When I think the result is good enough, I re-enlarge my canvas and start the render.  If it isn't as good as I though it would be based on the rough, I shrink my canvas a little less to see more detail while I fine-tune my settings.

Allow 3D preview size/scale to be different from finished render size. Add an option for a scaling factor (keep aspect ratio), and/or automatically compute scaling factor when the preview window is resized. Scale down the canvas for 3D preview purposes to this scaled size. When rendering, render the frame internally at full resolution, but scale down the output to this size just for display purposes (the frame-save/dump are still full-resolution). For instance, if I have a 1440x900 monitor, but want to render a scene at 2560x1920, and also have on-screen room for the renderer controls, I may want to scale the preview window down to 0.5x or less. Currently, I can resize the window by hand, but (1) it doesn't constrain the aspect ratio so my preview may be distorted, and (2) it still internally renders the preview at full resolution, wasting CPU cycles on pixels that will be discarded while I'm navigating the world and/or adjusting settings. /Warr1024 (talk) 17:55, 9 July 2012 (UTC)


 * Perhaps you could add the texture pack chooser and waterworld option in the 3D preview window. Kinda sucks to have a really nice angle, just to find out you did not select waterworld..

Sky

 * [[File:Lilypad.png]] Add options to change skymap rotation / make skymap rotation independent of sun rotation


 * Adds templates for skies.
 * This will be added eventually. /Jesper Öqvist (talk) 16:15, 12 June 2012 (UTC)


 * [[File:Lilypad.png]] Add a button to unload the custom skymap and use the built-in default. Currently, once a skymap is loaded, it's easy to change it to a different custom one, but there's no easy way to go back to the default built-in model.

Lighting

 * Artificial sun model in the sky.
 * The sun is rendered as a white disc in the 3D preview. It is sometimes not that visible because the sky texture may be mostly white in the same area. /Jesper Öqvist (talk) 09:13, 1 June 2012 (UTC)


 * Either a slider to increase a torches affect area or a hard code to do this, rendering a night scene as i type this and torches almost have no effect on anything more than a block away. Example image
 * This is because torches emit the same amount of light per surface area as other emitters, but have a much smaller surface area. I work around this by lowering the sun intensity (choose a darker sun color), darkening the skybox, and raising the gamma.
 * I would like to add an option to change emitter intensity. Not had time to do that yet. /Jesper Öqvist (talk) 16:13, 12 June 2012 (UTC)


 * How easy would it be to add an option for biased rendering in regards of the lighting? I think currently, you need LOTS of SPP if you use light emitters, simply because esp. torches are so small, and the probability that a ray hits a torch is quite low. How about there is a certain (not too high) probability that a reflected ray heads towards one of the 3 (4? 5?) nearest light sources? (but ONLY if that ray actually reaches it and is not obstructed by anything. Also, the distance of that light source should be taken into account for the probability) -- It might be tricky to get the variables right and not to lose (visible) quality compared to an unbiased rendering, but it should be possible to get that balanced. It should speed up rendering by a lot (or more precisely, require much less SPP). --John Doe (talk) 14:40, 6 August 2012 (UTC)
 * Ugh, I only started reading about ray tracing after I suggested that, and tried to implement that feature. Turns out it's not that simple. I'm currently waiting for comparison screens to finish, but the lighting looks different. But in general, Bidirectional Path Tracing seems to be close to what I had in mind. --John Doe (talk) 23:58, 8 August 2012 (UTC)
 * Seems like this isn't causing too much excitement, but I still want to share my result: Comparison shot .. The biased version is much brighter, so I had to lower the emitter intensity. Turns out I lowered a bit too much, because now it seems darker than the comparison screen. No gamma correction was applied. You can see that the biased version is a lot less grainy, but the lighting looks different, not just because of weaker emitters. I think that bi-directional approach mentioned above might turn out way better than my cheap and stupid approach and actually really improve render speed without screwing up the lighting. But maybe you actually want a uniform unbiased tracer? --John Doe (talk) 02:21, 10 August 2012 (UTC)
 * I have been planning on experimenting with bidirectional path tracing and progressive photon mapping for some time now. Unfortunately I have not yet had time to do much testing with these techniques yet. Thanks for sharing your results! /Jesper Öqvist (talk) 09:09, 11 August 2012 (UTC)

SPP Control
I'm sure people can do this on there own, and I'm aware that the pictures never really finish, depending on how long the user waits the higher quality picture they will get. But I think while rendering there should be a progress bar based off how many SPP the user wants. Let me explain. The user would setup what he wants in the picture then he would select the quality level. Low quality maybe about 250 SPP, medium 500 SPP, high 1000 and very high 1500. That or they could manually input the SPP themselves. (I'm just guessing based on what I've seen.) Then based on the average amount of time it takes for ever pixel to be sampled in one go would give us a rough time frame of how long it will take.
 * A more useful way to control SPP may be to allocate more samples to darker areas of a scene. This is because indoor/night renders take more SPP to look equally smooth than outdoor well-lit renders.  Perhaps a slider of a luminosity threshold (initially 100%), above which (based on the so-far-rendered image) additional samples will not be taken, which can be changed during a render without resetting it (changes take effect on the next sample pass).  In a mixed dark/lit scene (e.g. looking into a cave entrance), the user could start the render at 100%, and the well-lit areas will resolve fairly quickly.  The user could then lower the threshold slider to focus more computing power to resolving the dark portion.  The user could also increase it back when the dark areas are starting to look good, to add more quality to the overall image.
 * This is an interesting idea. I've been wanting to implement HDR rendering. It would probably be possible to combine tonemapping and selective SPP priority. /Jesper Öqvist (talk) 22:40, 8 June 2012 (UTC)

GPU Rendering
Is there any posibility that this could ever use CUDA to speed up renders? I do a lot of GPU rendering at work, and the speed increase really is quite amazing.
 * I am working on an OpenCL implementation. However, it is A LOT of work and I have no idea when it will be finished if ever. /Jesper Öqvist (talk) 11:33, 1 June 2012 (UTC)


 * You are right, it is a lot of work. Thanks for making it, and thanks for the reply :)

Other features

 * It's not by any means essential, but it's a simple change: You could make it so that the text panel that tells you the render time, SPP, etc. was not editable, because you can change the text, although it updates every second or so. I know it's not very important, but considering it's a simple setEnabled(false), I figure you could do it.
 * Could you make an option for worlds or selected chunks to be exported to 3D programs such as Blender or Maya?
 * There is already a tool to do that: j-mc2obj I've heard that it's quite excellent. /Jesper Öqvist (talk) 07:41, 4 June 2012 (UTC)


 * Chose to turn on and off the display of the rendering image.
 * I've been planning this feature for a while, but have not started implementing it. /Jesper Öqvist (talk) 09:17, 1 June 2012 (UTC)


 * The option to Input SPP amount, or chose pre-set SPP's "Low,Medium,High" or just let the image constantly improve.


 * Option to have improved lava. (Just as water differs from the game but this one is a maybe.)


 * Adds saturation bar with gamma.


 * Adds folder in Chunky that Saves developing picture and name them Chunky_1 and when you start a new rendering image it saves as Chunky_2 (or something of that nature so it doesn't replace images if you've forgotten to save them.)
 * Good suggestion /Jesper Öqvist (talk) 09:17, 1 June 2012 (UTC)


 * Adds low resolution preview option even if you have selected a higher rez. (I've noticed when I chose higher resolutions the picture sometimes never loads so I can't start rendering)


 * More realistic redstone - possibly some sort of preliminary redstone simulation using one of the open-source redstone sims to get a realistic redstone look
 * Better redstone rendering will be implemented eventually. I don't think I will add redstone simulation though. Chunky was not inteded to simulate the dynamic behaviour of Minecraft, it should only render it as if everything were frozen. /Jesper Öqvist (talk) 16:13, 12 June 2012 (UTC)


 * Water flow simulation (like minecraft's water-flow, not anything complex like fluid sims) so that waterfalls look more realistic --71.238.150.124 23:09, 7 June 2012 (UTC)
 * I'm working on this /Jesper Öqvist (talk) 16:13, 12 June 2012 (UTC)


 * [[File:Lilypad.png]] Default the number of render threads to the number of processor cores/threads. Currently it looks like this is hard-coded to 6.
 * This feature is committed and ready for 1.0.7 /Jesper Öqvist (talk) 17:12, 14 June 2012 (UTC)


 * [[File:Lilypad.png]] Distance fog to make the render of large areas more realistic, and provide an added DOF.


 * Make mobs visible
 * Entities will be added in the future /Jesper Öqvist (talk) 12:20, 13 July 2012 (UTC)


 * It should be quite simple to add 16bits/channel png output. That way one could do advanced gamma correction and image processing afterwards without losing notable image quality. It would be nice if in this mode, Chunky would not apply any gamma correction, and would check the image for its min and max brightness levels, and map that to 0/65535 in the output image. This would ensure that the material for further processing has the best possible quality. --John Doe (talk) 14:46, 6 August 2012 (UTC)


 * Add a "Grass World" option, similar to Water World, to help with rendering SuperFlat maps. Better yet, merge these two features and allow the user to choose a material. --Warr1024 (talk) 22:01, 28 August 2012 (UTC)


 * I really miss the look of "better grass/snow" … makes the render look more lively … esp. when you have landscapes with more flat and more rough hills. you would get nice seamless patches of grass/snow between rougher dirt/stone cliffs. i don't like those grass-dirt-grass-dirt-grass-dirt… staircases … thx :) --0m1k 77.12.192.0 13:46, 22 September 2012 (UTC)


 * Normal/Bump mapping and specular maps (where black means perfectly diffuse surface and white mieans perfect mirror)


 * Torches should emit light from larger sphere-like volume, not just form the texture. This would not only simulate the size of the flame, but it would also introduce less noise.


 * Fresnel reflection and refraction of glass and glass panes


 * Alpha transparency between 0 and 1 for water. Rendering underwater objects by looking down on them is currently impossible since the water is so dark. So basically the water should have an option to be transparent where a user can control how far they see into it or something.


 * It would be awesome, if you could add a feature, with that you can export your scene with all settings, so you could render your scene on a server (with a terminal)


 * Plants (grass, flowers, etc.) currently all render at the same position and rotation in their "block", leading to very repetitive rendering when in a field (along with shadows, depending on the angle they'll only be half lit, etc.) A slight rotation/translate would break that up and make plant rendering much nicer.

Done
These features have been implemented in Chunky:

Point and click to select focal point.
 * This was implemented with the autofocus feature in 1.0.5. It's not point-and-click but autofocus will put the focal offset at the block in the center of the view. /Jesper Öqvist (talk) 16:15, 12 June 2012 (UTC)

Distributed Rendering
I'd love to see a way to have multiple people from my server download Chunky and join a group to help distribute the rendering of the image. Imagine how much faster a render could be accomplished if a dozen machines are splitting the rendering burden! I'm going to be doing some Chunky renders on my server but this idea just floated into my head so I thought I'd share it with you!