rendering sequence

Deprecated Krakatoa VRY Beta Discussion
21

I checked and that frame is zero particles content, I will launch it from further along and report back. But it seems that when when you launch a rendering sequence for the first time in a fresh folder if it encounters zero particles it stops however if you relaunch the same render and it dosent have to export particles again its fine.

The other thing I noticed is that, say you render frame 20-200 and then its exports the vrscene for those frames if you want to rerender a new frame range (100-200) everything remaining the same it starts exporting the scene again which seems unecessary.

I tried using a realflow .bin mesh and it wouldnt render as in it would render the the particles but not the waves. is this unsupported as of now?

22

I suspect there might be something about 0 particles files. When I get back to my workstation later this week, I will test that myself.

I am not sure I can do much about it, as we don’t track changes to the scene. If you moved a camera or flipped a checkbox somewhere in Max that would affect VRay, we need to make sure it is reflected in the render. So we always export the vrscene (unless you specifically disabled it) to make sure it is up to date. I will have to check if it would be possible to launch vray.exe with an existing vrscene but with a new frame range.

That could be a limitation of the BIN mesh loader by NextLimit, or of V-Ray scene exporter. I don’t think we could fix this issue on our side, as we don’t control either. I would have expected the vrscene exporter to bake the mesh into the .vrscene file. I believe it works with XMesh for example.

23

Tried from a point where there are particles in the scene having the same issue renders first frame and then the same error about GI. Logs below.

Regarding the reexporting of the file when changing frame ranges I had turned off export vray scene and it still exported.
render_error2.txt (17.1 KB)
loggg.log (69.7 KB)

24

This is As Designed:

if not chk_exportVRScene.checked and doesFileExist thePath do needExport = false

We not only check whether the vrscene export checkbox is unchecked, but also whether the requested filename exists already. Since changing the range changes the file name of the vrscene (the range is part of the name), it will export again even if you unchecked the option. The only case it will not reexport is if you have already saved a vrscene with that interval in a previous attempt.

For example, you export frames 0 to 100 and they render. Then you uncheck the option to export the vrscene and render 0 to 100, the existing vrscene file will be re-used. You change the interval to 10 to 100 and export with the vrscene option unchecked, but a vrscene for that interval does not exist yet, so a new one is saved anyway. You then re-render 10 to 100, no new vrscene will be exported because of the previous export. Now you check the option to export vrscene, try to render 10 to 100, and a new export will be performed. You uncheck the vrscene export option, change the range to 0 to 100 again, and the old existing 0 to 100 vrscene will be reused without export…

That being said, it looks like vray.exe can be called with an argument to render a specific frame range from an existing vrscene file. This option is currently not supported by the KVRY exporter. I will look into what would take to support it using an existing vrscene whose interval is larger than the requested sub-interval. I am not sure I want to go there, but I might add an option to create a new BAT file for launching a user-defined sub-set using an existing vrscene file.

25

After looking a bit closer at the two logs you posted, I am a bit confused. The time stamps of the renderer and the exporter are off by 4 minutes. Were they from the same session?

KVRY exports the vrscene file and frame 0020, then it launches the renderer:

[2017/Mar/13|03:27:43] Starting frame 20.

It finishes that frame successfully and starts frame 21:

[2017/Mar/13|03:27:55] Frame took 12.03 s. [2017/Mar/13|03:27:55] ======================== [2017/Mar/13|03:27:55] Starting frame 21.

However, the export of the rest of the frames 21 to 200 does not start until 4 MINUTES later!

2017/3/13 03:31:56: >BAKING the rest of the PRT files for frames 21 to 200

So the problem is not in the renderer / plugin not finding a file that is there, the frame 0021 is REALLY not there when it is searched for, as it was exported 4 minutes later.

Can you please confirm that the two logs below come from the same session? Can you tell me what happens in the Krakatoa VRY exporter between the launch of the VRay stand-alone and the export of the rest of the frames? Can you post the WHOLE log from the Krakatoa VRY exporter so I can see the time stamps of all export operations, including frame 20? Right now I don’t have anything before the like I quoted above, so I cannot tell where those 4 minutes were spent… The matching VRay log would also be needed to compare the time stamps.

Thank you very much for your patience!

26

hi bobo

It might be better to analyse the second set of logs that I uploaded as attachments. I thought I had pasted the full log before but maybe i missed something out.

It starts exporting the PRT files and the the VRscene, I saw the files being created in the folder.

27

Oh, thanks, I can see what is happening now.

We are cleaning up the frames before exporting them to ensure that the renderer won’t find anything old. But the deleting takes forever - nearly 200 frames take from 19:04:13 to 19:08:41 which is over 4 minutes. In the mean time, the renderer fails because the next PRT file it needs has not been exported yet.

I will have to rework the exporter to avoid this. Not sure how yet, but I will find some way…

However, this would be an issue only when re-exporting to the same version folder - if saving to a new version, I would expect it to work without a problem.

28

Interesting, it makes sense thats why it works the second time around.

I have been exporting to a new folder everytime btw.

29

I just notices that you did

2017/3/16 18:16:09: +SWITCHING Project [sub] to NEW Version [v016]

So the main bug here is that it claims it is deleting files which do not exist, and it is taking 4 minutes to do so.
I need to address this first.

Basically the idea is this:

  • If you were rendering to an existing folder, and the PRT object had changed, we would need to delete any frames whose hash checksum does not match the current state of the object. This is to prevent the renderer from using any outdated particles. Then we would reexport any particles that were deleted in the previous cleanup pass.
  • If nothing had changed (PRTs on disk match the content of the scene), nothing would be deleted or exported again - this is why it renders if you reuse an existing version folder with unchanged scene
  • However, if you start a new folder, it incorrectly assumes files that do not even exist on disk and thus have no hash checksum at all need to be processed, and it spends 4 minutes on this where it should not.

So I need to deal with two cases - the one should really fly through the process because there is no data to clean up, and the other should process a few frames first before starting the renderer to avoid the starvation for data…

Thanks for the help, really appreciated!

30

Please give this updated script a try…
KrakatoaVRY_Exporter_20170321.zip (34.9 KB)

31

Hi Bobo

Seems to be doing the same thing have attached logs.
23_march_cmd_log.txt (18.5 KB)
23_march__log.txt.log (69.7 KB)

32

I can easily tell you are not running the latest script :slight_smile:

The new script does not report any cleanup “deleted…” lines when performing a first export to a new version. Also, if it was performing a cleanup on an existing version folder, it would do it in batches of 10 - it deletes 10 PRT files, then exports the new 10 PRTs to replace them, then repeats for the next 10 and so on.

No idea what you did with the script I posted, but you did not end up using it. Did you copy it into your KMX 3.0 Beta installation’s \Scripts folder? If you cannot do that due to permissions, you could temporarily just drop the new script into the viewport of 3ds Max, wait for the MAXScript Listener to report the MacroScript number (it can take up to 10 seconds before it is evaluated), and then launch from the Krakatoa menu. If you restart Max, the old script will be used, so you need to drop the new script each time, unless you managed to replace the MS file in the \Scripts folder…

33

:slight_smile: odd I swear I did it , first thing i checked it had the date modified from today. Let me try again.

34

It might be failing to load. Running the script manually ensures you are running the latest one. I might add a date stamp to the log in the future so it is clear what version is running…

35

running the script manually did the trick its rendering now. Great stuff.

I was wondering for refraction does the number of particles or voxel size make a diffrence for the speed of rendering? Also I might have missed it but is there help files about the different sections? I was wondering about alpha threshold in particular

36

There is no help yet, I should probably start making one :slight_smile:

For refraction, we perform raymarching through the volume similar to what the Krakatoa Atmospheric effect does in regular Krakatoa. So the performance depends on the size of the voxels, and how deep we march through the volume before we stop. That’s where the Alpha threshold comes to play.

Imagine you have a grid of 10x10x10 voxels. Each voxel will have Color, Density etc. set from all particles in it. We march a ray through the voxels. We enter a voxel and step through it until we exit it, and record the amount of Density collected for that interval of space. We continue marching through the next voxels until we exit the grid, or until the Alpha Threshold is reached. If the Alpha Threshold is close to 1.0, it means that we don’t give up until the ray has collected enough Density for the camera to see a SOLID volume from that point on. Obviously, if we marched through 5 voxels and collected a fully opaque Alpha, it makes no sense to continue as we would not see anything more behind an opaque pixel. So this saves a lot of marching that would not affect the result.

However, if you lower the Alpha Threshold, you are basically giving up early, even before the whole volume has been traversed by the ray. This is usually a good idea for the GI contribution (which uses its own separate grid settings), but for Reflection/Refraction it would drop a lot of data that would be potentially visible. So the look of the Refracted voxels would change a lot, basically you would take into account only particles that are close to the surface of the volume, and skip stuff deeper inside to gain some speed.

So you can tweak the Alpha Threshold to balance quality vs. speed - the higher the value, the slower and closer to the highest possible quality the result will become.
Large Voxel grids will be more fuzzy as more particles would be averaged in a voxel, but also much faster to march through…
And of course the number of samples VRay itself has to calculate affects the number of rays to be marched, so that is yet another factor to keep in mind…

37

finally got around to finishing that render, takes approx 10 mins on my machine per frame. The vray version without the particles takes less than a minute. So its quite a hit in terms of rendering times but you do get some nice results where the particles refract just under the surface as you can see in the refraction pass . Also some blocky black patches appear in the refraction not sure where thats coming from.

vimeo.com/213986221/59a72d193a

The sim is a bit low quality so there are some artifacts. Unrelated to KRK VRAY but its really annoying that the PRT from realflow HYBRIDO dosent come in the correct way. I had to rotate and mirror the PRT loaders.

38

Thanks for the test! The particle refraction currently uses the Krakatoa Atmospheric code under the hood, which is known to be relatively slow. We will be looking into accelerating refraction calculations in the future.

We will have to look into those blocky black patches, I am not sure where they are coming from either.

I have been telling people this for a while now, but I will repeat - do not save PRTs from RealFlow, save BINs or RPCs and load them in the PRT Loader - it will do the scaling and rotation under the hood, plus it won’t have incorrect channel names some versions of RealFlow produced (mainly capitalization of some channel names caused them not to load as the correct data in Krakatoa - e.g. “Id” channel is not the same as “ID”). This might have been fixed in the most recent RealFlow, but I have not checked.