-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Larger Canvas Size Support #786
base: master
Are you sure you want to change the base?
Conversation
As discussed on discord, this is a temporary solution at best, and proper render regions would be the better approach. |
This pull request is marked as a I believe it has done better than master in most of the test cases due to a couple slight changes in a few of the files that were made, so I will be creating a separate pull request to fix a couple of those things, should they prove to be the cause of increased efficiency. |
At the very least this Draft does not reduce performance. |
@StanleyMines This PR (along with #798) is pretty much exactly what I'd need to add non-uniform sample distribution (canvas cropping, selective rendering, …). The performance seems to be slightly better than before, this PR looks pretty good. Is there anything (other than the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see why this shouldn't be merged. It's great! 😮
chunky/src/java/se/llbit/chunky/renderer/scene/SampleBuffer.java
Outdated
Show resolved
Hide resolved
chunky/src/java/se/llbit/chunky/renderer/scene/SampleBuffer.java
Outdated
Show resolved
Hide resolved
chunky/src/java/se/llbit/chunky/renderer/scene/SampleBuffer.java
Outdated
Show resolved
Hide resolved
chunky/src/java/se/llbit/chunky/renderer/scene/SampleBuffer.java
Outdated
Show resolved
Hide resolved
chunky/src/java/se/llbit/chunky/renderer/scene/SampleBuffer.java
Outdated
Show resolved
Hide resolved
* SampleBuffer class to hold the sample buffer and alpha buffer of render as double[][] instead of double[] * Changed BitmapImage class to use int[][] instead of int[], to be consistant with SampleBuffer * Made BitmapImage.data protected for better encapsulation. * Refactor things to work with the new SampleBuffer and BitmapImage. And use the getters and setters instead of directly accessing array (which is faster in most cases too). * Fixed wrong comment in FloatingPointCompressor class for decompression logic * PngFileWriter now takes BitmapImage instead of int[]; PfmFileWriter does similar internally. * BitmapImage function local variables refactored to correct names. * BitmapImage#vFlipped() now uses System.arraycopy and is thus much faster. Known Issues: * Denoiser plugin no longer can directly access double[], and will need to be updated to use the SampleBuffer (and while changing that, may as well switch to the existing PfmFileWriter) * Limits "Render Preview" canvas size in RenderCanvasFx class to prevent strange JavaFx crashes. This should be changed in the future. The current state can only view the top left corner of the render. I might change this to only show the middle 4k x 4k section, but ideally we should have some zoomed out preview which isnt so big that it crashes (and doesnt take much CPU time away from actual rendering).
Minor changes like rename and slight logic changes, and: Now using the `int[][] spp` to store spp for each pixel; this will increase memory use a bit, but also opens the door for not rendering the whole canvas at the same time. This is not fully implemented yet, as Scene#spp is used pretty much everywhere still.
Un-'draft'ed this PR. Still need to fix test cases, though I think everything else is working fine atm. (@leMaik knows more about what exactly needs to be done.) |
int pixels = input.length / 3; | ||
int size = pixels - 1; | ||
|
||
long size = input.numberOfPixels() - 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this change! Could you do the same in the decompress
method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do 👍
Note: Hard coded 4096x4096 display instead of full image is not sufficient. This still crashes chunky on my other computer, when using my second monitor. |
This seems to depend on the windowed size of the chunky GUI itself. When it is large (5000x3000 ish) it crashes at small sizes (2.5k by 2.5k) when window is small (900x300) it can do a bit larger (5kx5k), although I cannot seem to get larger than 5kx5k even on single display, and minimal window size, at least on this computer. (Java 11.0.3 + JavaFX LTS 11.0.2; as well as java 1.8.0u281) |
Both the UI and Canvas need access to the same Texture from what I can gather with JavaFX. The maximum supported texture size depends on the GPU, driver, and D3D/OpenGL pipeline used.
|
I've not followed this too closely but what I suggest is to limit the on-screen canvas to have its biggest dimension be in some interval, let's say [1000; 2000] px. You then take the biggest dimension of the real canvas and you divide it by 2 until it falls into the interval. For example, for a (imaginary) 76005100 canvas, you do the division twice to get an on-screen canvas of 19001275 which javafx supports without issue and each on-screen pixel correspond to 4*4 pixels in the real canvas, that's a round number easy to deal with. |
@StanleyMines I'd like to drop the changes done to
This would allow people to manually split their images into tiles and merge them, it could also be automated by automatically generating the json files (we'd need some new property like Once that's done, we can always come back to this and add a nice UI or a view for the entire image. But the most important aspect about this is to be able to split large resolution jobs into multiple smaller jobs, which is not possible at the moment. |
Downscaled preview should no longer crash on 99% of computers, and will display entire render. We should really have some way to set previewShouldSubsample, though I havent implemented that yet. Preview render should probably also only show up to the max shown size instead of rendering far more pixels than will actually be shown. Its a preview afterall, is it not? We should probably update preview scale %s. (And this should work great with @alexhliu's new auto-scaling preview PR)
Fixed compile error.
Added Downscaleing to render previews:
Fixed Merging:
Future things to consider doing:
|
Fix conflict to be able to merge into master.
This should fix the issue described in #492 where a single array cannot hold the whole image, however I just realized that #492 does not mention the issue of |
* Improved alphabetical sort by scene name to now ignore case (unless they are otherwise identical) * Render Time column now has reasonable formatting ("4hr 07m 14s" instead of "4:7:14", or "8s" instead of "0:0:8", or "—" instead of "0:0:0") * Changed column widths to more reasonably fit their data (and no longer have very weird numbers as widths) * Size column now will have the crop size in brackets, if the scene is defined as a subarea in the .json. * Renamed window "Load Chunky Scene" from "Select 3D Scene"
Updates:
Things left to do in this PR:
For the future (probably not this PR):
|
@leMaik said:
So I guess there is (at least) one more thing to do here... |
Further testing needed to make sure this actually works.
Note: this removes tests on the merging for this format. They will need to be added back eventually. Current issue is that the existing code either: 1) does not work with GZIP, or 2) doesn't test the new features of this format's merging (variable spp & cropped dumps).
Oop -.- (this was added a few commits ago when I was testing stuff and the end of file wasn't where I expected, and I wanted some breathing room.)
Removing 512 changes the file. Who would have guessed.
IntegratedSppDump now uses gzip to compress all of the dump after the header. This is slower than the floating point compressor by a bit, and is far far slower than uncompressed, but is capable of saving ~10% size. Merge testing is currently not functional for the new features though. Next thing I plan to work on is adding some (jank) UI way to subdivide a scene and possibly move to the next subarea to render. (I'll fix dump merge test once theres a better solution to compression... atm I don't think its worth putting in more effort to get the test to pass (more than implementing the compression), if I know its working right now and its probably going to be changed very soon...) |
@StanleyMines Sounds good 👏 Maybe do the UI on a new branch so that we can finally get this feature merged when the compression is ready |
Still happens on occasion... Seems to be a synchronization issue.
Primary goal is to fix #492 which caused crashes at various "large" resolutions for different people.
Known Issues: