Feature/network rendering #101
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I just now decided to go with a different approach. Instead of having whole separate codepaths for managing a network-enabled render, I'll just have network-enabled render threads that poke at the worker clients to get their work done. Should integrate better with the rest of the system. Right now networking.c contains a lot of the previous approach I was trying, that will go away, probably. Just stashing these changes in version control now in case my computer crashes.
Test suite needs to be expanded, obviously. Implementations lifted from stackoverflow here: https://stackoverflow.com/questions/342409/how-do-i-base64-encode-decode-in-c The implementations chosen are far faster than anything I could ever come up with.
Was kind of confusing to just see nothing happen when invoking run-tests.sh
It was just indexing into the wrong array when printing the name.
It now sends a header of the message size as a 64 bit integer in network byte order, and then sends the message content in 1kB chunks. Seems to work, but I wouldn't be surprised if there were some bugs in there still.
Also set it back to doing some protocol messaging.
It's starting to exchange messages, but there is something wrong with state encoding. I'm pushing these now because I'm going mobile for the weekend.
Didn't allocate enough bytes for the output buffer.
The default buffer is 512 characters. Print any more than that and you get ellipsis at the end, indicating there would have been more text. This confused me much when I started debugging the protocol by printing the sent/received data using logr(). I forgot it was intended purely for short status messages, not for printf() debugging.
Won't be using them, I think. Also remove some debug prints that are no longer needed.
Sync mostly works now, but we need a nice solution for on-disk assets. I'm thinking of a fscache module where files can be stored in key-value pairs of type path-file.
This is used to easily send assets to worker nodes over the wire.
Was having some connection reset issues, this might help.
Stitch together the chunk if we didn't get it all on the first call to recv()
Also patch up base64 to fix an asan error
It's not available on linux, and might not be needed. I just added it before to try and resolve connection issues.
Settings like image or tile dimensions and sample count must match those of the master node, otherwise the resulting image will not turn out right.
Now has proper timeouts, and connects just once.
Also a few rather obvious bug fixes.
Just a simple approach for now. At the end of a render, check and see if any network rendered tiles were left unfinished, and assign those to local render threads.
I don't have a windows box to test on, so I have to commit & push to see what the github CI has to say about it.
3 tasks
Split up protocol.c into server.c and worker.c Still very rough, just split it up and fixed build errors.
Would be useful if MSVC reported more than 1-3 errors at a time.
For scenes that load the same asset more than once, it just got stuffed in the cache multiple times, and worse, sent over the wire to every client. This patch fixes that - no more redundant data.
Just some status updates while assets are being transferred, since it can take a while.
And apply it to texture loading as well.
256 was a bit small for path length there.
For some reason unknown to me at this time, building with MSVC in Release mode causes c-ray to crash when evaluating materials. This will need to be debugged further, but for now we can disable alpha blending on Windows so it can at least render something without crashing.
New windows build instructions (the build works again) Link to network rendering doc
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is starting to look like it's good to merge now. Few more TODOs: