I have a Java application that creates a scene and calls rtrace with a big number of rays. At first I did it passing the rays in a file with no problems. In total each time it created ray files in the order of GB, which seemed a lot of data to write and then delete on the disk at the end so I decided to change it to streams where I could write directly the input rays and read the results from the output stream.
I have found that running rtrace using streams have a very limited amount of data I can input each time (it seems like 4094 characters by trying it in the terminal). I got some problems in my program when trying to put more than 60 rays or so like getting stuck when trying to write rays in the input stream or when it waits indefinably for rtrace to finish.
My question is if anyone knows if doing it with streams is a good idea, if there is some open projects or repos as an example and if there is a way to input more rays with streams so I don’t have to write and read that often from the program. It is entirely possible that I’m doing something in the wrong way as I don’t usually interact directly with binaries in my apps.
This seems like a Java-specific question. I don’t know why taking data from a stream would make any difference to rtrace, since the system handles data buffering for the most part. There are some games you can play if you know rays are coming in batches of a certain number using the rtrace -x option, which enforces flushing after the specified number of rays. I don’t know how Java handles its data, but this might be worth a try.
Thank you for the suggestion. I will try setting the -x option to my number of rays.
I still have the doubt about the 4094 characters limit that I get in Windows’ Command Prompt and PowerShell when inputting the rays to rtrace. My thought behind it was to try to simulate what my app does with batches of rays by separating them by a space character instead of a new line. I don’t know if that makes any difference to rtrace or if that is handled by the system, but it seemed important to me as that range of input size is where my app starts failing.
I think I’m hitting the pipe buffer limit, although it seems really small, but I checked that I can flush that one and write again more times before I have to start reading the output, so I managed to get a bigger batch size of rays.
Thank you for the tips.