Video Renderer for 3D VR180, VR360 and Flat 2D & Audio + BVH Animation Recorder

Plugins Video Renderer for 3D VR180, VR360 and Flat 2D & Audio + BVH Animation Recorder

Download [0 MB]
Overview Updates (15) Reviews (41) History Discussion
I know Eosin hasn't been around for awhile so I'm not sure if anyone out there can help me but I was working on my latest video and everything was fine, then suddenly my audio captures greatly reduced in quality, the difference is definitely noticeable. The audio in game is still perfectly clear and crisp but for some reason the .wav file that is created has noticeable peaking. I tried reloading the plugin and various other things but no luck.
 
Is it possible to render out Flat 3D SBS videos using this plug in?

I’ve just started working with this, and the results are great for vr180 and flat so far. I just can’t piece together if flat 3d sbs is possible.
 
Why do I make rendering errors while running the SSS plugin simultaneously.
20231219-034442.jpg
 
First I just want to thank Eosin on this awesome/useful plugin. Though, can someone explain how to make the video duration longer? I've been using it and it records 10 seconds by default it seems. I see the option for video time but that seems to not do anything when I change the value. How do I make this plugin record longer? Ideally 1 minute would be nice as right now I'd just been saving 10 second clips and merging them into Avidemux but that is not ideal as every 10 seconds there are cuts in the video that are jarring.
 
infernohammer said:
First I just want to thank Eosin on this awesome/useful plugin. Though, can someone explain how to make the video duration longer? I've been using it and it records 10 seconds by default it seems. I see the option for video time but that seems to not do anything when I change the value. How do I make this plugin record longer? Ideally 1 minute would be nice as right now I'd just been saving 10 second clips and merging them into Avidemux but that is not ideal as every 10 seconds there are cuts in the video that are jarring.
Click to expand...
I've always rendered 1 minute long videos, flat 4K at 16:9. Perhaps you have an issue with lack of memory. Try rendering to JPG instead of PNG. I use 90% quality on JPG.
 
infernohammer said:
First I just want to thank Eosin on this awesome/useful plugin. Though, can someone explain how to make the video duration longer? I've been using it and it records 10 seconds by default it seems. I see the option for video time but that seems to not do anything when I change the value. How do I make this plugin record longer? Ideally 1 minute would be nice as right now I'd just been saving 10 second clips and merging them into Avidemux but that is not ideal as every 10 seconds there are cuts in the video that are jarring.
Click to expand...
It's in the settings of the plugin, I think it says seconds to record, it's on the left. I adjust that all the time for my renders with this plugin.
 
First of all: Great plugin, exactly what I was looking for!


TLDR: I made some experimental changes to it that seem to improve rendering performance quite a lot.


I've just gotten into VaM plugin development and have been experimenting a bit, and had a quick idea on how to improve the plugin's performance a bit. As Eosin reported, much of the time is spent in the JPEG/PNG encoding step, so I thought this might be improved simply with multi-threading: The frames can be rendered into alternating textures, and those textures are then encoded to JPEG/PNG in separate threads. This way, rendering and encoding happen simultaneously, and multiple frames can be encoded (not rendered) at the same time on multi-core processors.

I experimented a bit with this, and it turned out to be surprisingly simple and effective. The results depend quite a bit on the scene complexity, but testing with a pretty average scene and 4K Stereo180 JPEG rendering, I rendered with ~390fpm before the changes, and ~760fpm after. For PNG rendering, it seems to be even more dramatic, with ~150fpm before and ~570fpm after. I'm using an RTX 3060 Ti and a Ryzen 7 7700X. These were just very crude measurements and YMMV, but I think that's pretty good for something quickly hacked together in a day.

I've only done very basic testing, and I'm not that experienced with C#, so I'm not confident that it always works. But if someone wants to try it out, I've created a GitHub repository with the changes (it's really only Eosin_VRRenderer.cs that has changed). I've also uploaded a modified VAR file that should just work as a drop-in replacement. Multi-Threading is enabled by default, and there are two new UI controls in the very bottom right for setting the thread count (might have to try around with different values) or reverting to the old non-threaded behavior.
 
Dude, that is FANTASTIC news! I always render in flat 4k 60fps PNG, so I'm very excited to try this! I have a 7900x and a 4090 and I typically render around 130fps.
yunidatsu said:
First of all: Great plugin, exactly what I was looking for!


TLDR: I made some experimental changes to it that seem to improve rendering performance quite a lot.


I've just gotten into VaM plugin development and have been experimenting a bit, and had a quick idea on how to improve the plugin's performance a bit. As Eosin reported, much of the time is spent in the JPEG/PNG encoding step, so I thought this might be improved simply with multi-threading: The frames can be rendered into alternating textures, and those textures are then encoded to JPEG/PNG in separate threads. This way, rendering and encoding happen simultaneously, and multiple frames can be encoded (not rendered) at the same time on multi-core processors.

I experimented a bit with this, and it turned out to be surprisingly simple and effective. The results depend quite a bit on the scene complexity, but testing with a pretty average scene and 4K Stereo180 JPEG rendering, I rendered with ~390fpm before the changes, and ~760fpm after. For PNG rendering, it seems to be even more dramatic, with ~150fpm before and ~570fpm after. I'm using an RTX 3060 Ti and a Ryzen 7 7700X. These were just very crude measurements and YMMV, but I think that's pretty good for something quickly hacked together in a day.

I've only done very basic testing, and I'm not that experienced with C#, so I'm not confident that it always works. But if someone wants to try it out, I've created a GitHub repository with the changes (it's really only Eosin_VRRenderer.cs that has changed). I've also uploaded a modified VAR file that should just work as a drop-in replacement. Multi-Threading is enabled by default, and there are two new UI controls in the very bottom right for setting the thread count (might have to try around with different values) or reverting to the old non-threaded behavior.
Click to expand...
 
yunidatsu said:
First of all: Great plugin, exactly what I was looking for!


TLDR: I made some experimental changes to it that seem to improve rendering performance quite a lot.


I've just gotten into VaM plugin development and have been experimenting a bit, and had a quick idea on how to improve the plugin's performance a bit. As Eosin reported, much of the time is spent in the JPEG/PNG encoding step, so I thought this might be improved simply with multi-threading: The frames can be rendered into alternating textures, and those textures are then encoded to JPEG/PNG in separate threads. This way, rendering and encoding happen simultaneously, and multiple frames can be encoded (not rendered) at the same time on multi-core processors.

I experimented a bit with this, and it turned out to be surprisingly simple and effective. The results depend quite a bit on the scene complexity, but testing with a pretty average scene and 4K Stereo180 JPEG rendering, I rendered with ~390fpm before the changes, and ~760fpm after. For PNG rendering, it seems to be even more dramatic, with ~150fpm before and ~570fpm after. I'm using an RTX 3060 Ti and a Ryzen 7 7700X. These were just very crude measurements and YMMV, but I think that's pretty good for something quickly hacked together in a day.

I've only done very basic testing, and I'm not that experienced with C#, so I'm not confident that it always works. But if someone wants to try it out, I've created a GitHub repository with the changes (it's really only Eosin_VRRenderer.cs that has changed). I've also uploaded a modified VAR file that should just work as a drop-in replacement. Multi-Threading is enabled by default, and there are two new UI controls in the very bottom right for setting the thread count (might have to try around with different values) or reverting to the old non-threaded behavior.
Click to expand...
Dude you’re a freaking hero! I would get 130FPM before, now I’m topping out at 750FPM!!!! Freaking game changer bro! ?
 
yunidatsu said:
First of all: Great plugin, exactly what I was looking for!


TLDR: I made some experimental changes to it that seem to improve rendering performance quite a lot.


I've just gotten into VaM plugin development and have been experimenting a bit, and had a quick idea on how to improve the plugin's performance a bit. As Eosin reported, much of the time is spent in the JPEG/PNG encoding step, so I thought this might be improved simply with multi-threading: The frames can be rendered into alternating textures, and those textures are then encoded to JPEG/PNG in separate threads. This way, rendering and encoding happen simultaneously, and multiple frames can be encoded (not rendered) at the same time on multi-core processors.

I experimented a bit with this, and it turned out to be surprisingly simple and effective. The results depend quite a bit on the scene complexity, but testing with a pretty average scene and 4K Stereo180 JPEG rendering, I rendered with ~390fpm before the changes, and ~760fpm after. For PNG rendering, it seems to be even more dramatic, with ~150fpm before and ~570fpm after. I'm using an RTX 3060 Ti and a Ryzen 7 7700X. These were just very crude measurements and YMMV, but I think that's pretty good for something quickly hacked together in a day.

I've only done very basic testing, and I'm not that experienced with C#, so I'm not confident that it always works. But if someone wants to try it out, I've created a GitHub repository with the changes (it's really only Eosin_VRRenderer.cs that has changed). I've also uploaded a modified VAR file that should just work as a drop-in replacement. Multi-Threading is enabled by default, and there are two new UI controls in the very bottom right for setting the thread count (might have to try around with different values) or reverting to the old non-threaded behavior.
Click to expand...
This is huge!

You should really make a new update to the plugin and credit Eosin as that user seems to be gone at this point. This is too good to get buried in the discussion. I went from 150 fpm to 1200 fpm peak (although it did drop to 900 fpm over the course of the recording). I can imagine this could get brought even closer to real-time with additional ideas and support from the community.

Can you explain in more detail how the multithreading works? I got great results at 8 and pushing that higher led to higher fpm, but also seemed to cause some short-lived freezes but my CPU and GPU were only at about 70%. Maybe I was read/write limited here? If so I bet swapping to jpg could boost my fpm even higher.
 
ehowin said:
This is huge!

You should really make a new update to the plugin and credit Eosin as that user seems to be gone at this point. This is too good to get buried in the discussion. I went from 150 fpm to 1200 fpm peak (although it did drop to 900 fpm over the course of the recording). I can imagine this could get brought even closer to real-time with additional ideas and support from the community.

Can you explain in more detail how the multithreading works? I got great results at 8 and pushing that higher led to higher fpm, but also seemed to cause some short-lived freezes but my CPU and GPU were only at about 70%. Maybe I was read/write limited here? If so I bet swapping to jpg could boost my fpm even higher.
Click to expand...
That's VaM itself lagging, in other words, VaM isn't keeping up with the plugin at that point. I've experienced the same. It's especially true the more you overload a scene. I had a scene with 4 person atoms, 8 lights, water effects, etc. I have a 7900x and a 4090 and realtime I was getting around 12fps. The plugin was rendering at around 400fpm (4k, 60fps, highest possible settings) with constantly stuttering/lagging, but on scenes with 2 person atoms and less lights it never chokes.
 
yunidatsu said:
First of all: Great plugin, exactly what I was looking for!


TLDR: I made some experimental changes to it that seem to improve rendering performance quite a lot.


I've just gotten into VaM plugin development and have been experimenting a bit, and had a quick idea on how to improve the plugin's performance a bit. As Eosin reported, much of the time is spent in the JPEG/PNG encoding step, so I thought this might be improved simply with multi-threading: The frames can be rendered into alternating textures, and those textures are then encoded to JPEG/PNG in separate threads. This way, rendering and encoding happen simultaneously, and multiple frames can be encoded (not rendered) at the same time on multi-core processors.

I experimented a bit with this, and it turned out to be surprisingly simple and effective. The results depend quite a bit on the scene complexity, but testing with a pretty average scene and 4K Stereo180 JPEG rendering, I rendered with ~390fpm before the changes, and ~760fpm after. For PNG rendering, it seems to be even more dramatic, with ~150fpm before and ~570fpm after. I'm using an RTX 3060 Ti and a Ryzen 7 7700X. These were just very crude measurements and YMMV, but I think that's pretty good for something quickly hacked together in a day.

I've only done very basic testing, and I'm not that experienced with C#, so I'm not confident that it always works. But if someone wants to try it out, I've created a GitHub repository with the changes (it's really only Eosin_VRRenderer.cs that has changed). I've also uploaded a modified VAR file that should just work as a drop-in replacement. Multi-Threading is enabled by default, and there are two new UI controls in the very bottom right for setting the thread count (might have to try around with different values) or reverting to the old non-threaded behavior.
Click to expand...
This truly is game changing, cuts my production time roughly by 60%. Thank you for this!

As an unrelated question, does any one know if there is a way to attach the VR render plugin to the male's head in scenes? Kind of like the embody/passenger feature when playing in VR? I ask because I have some scenes where there is a lot of movement and moving around the scene such as a giantess picking up the male model.
 
infernohammer said:
This truly is game changing, cuts my production time roughly by 60%. Thank you for this!

As an unrelated question, does any one know if there is a way to attach the VR render plugin to the male's head in scenes? Kind of like the embody/passenger feature when playing in VR? I ask because I have some scenes where there is a lot of movement and moving around the scene such as a giantess picking up the male model.
Click to expand...
Parent the Empty to his head?
 
SlimerJSpud said:
Parent the Empty to his head?
Click to expand...
Any way you can explain this in more detail? I can either click on the Empty or the HeadControl. I see options for both for Parent Link and Atom Linking and I'm not sure how to configure this.

Edit: Nevermind I think I figured it out!
 
Last edited:
Hey i am using this addon, but some animations are way too fast once fully rendered.

Example: I am using the Demon Stroking scene.
In that scene the Person is breathing at a specific rate, but in the rendered video only the breathing is at an abnormal rate, the rest of the body seems to behave in order.

Is there a way to fix this?

Cheers
 
ElGato said:
Hey i am using this addon, but some animations are way too fast once fully rendered.

Example: I am using the Demon Stroking scene.
In that scene the Person is breathing at a specific rate, but in the rendered video only the breathing is at an abnormal rate, the rest of the body seems to behave in order.

Is there a way to fix this?

Cheers
Click to expand...
I'm all very new at this myself but I've had this happen in some pre-made scenes as well. I think the way the animation is handled in some scenes doesn't play nice with the VR renderer. For most of the videos I've made it's been good but for some I've had jittery facial animations especially.
 
infernohammer said:
I'm all very new at this myself but I've had this happen in some pre-made scenes as well. I think the way the animation is handled in some scenes doesn't play nice with the VR renderer. For most of the videos I've made it's been good but for some I've had jittery facial animations especially.
Click to expand...
This issue is it never even shows a preview, just an empty box and if I try to render or even take a picture using the renderer then VaM freezes.
 
ElGato said:
Hey i am using this addon, but some animations are way too fast once fully rendered.

Example: I am using the Demon Stroking scene.
In that scene the Person is breathing at a specific rate, but in the rendered video only the breathing is at an abnormal rate, the rest of the body seems to behave in order.

Is there a way to fix this?

Cheers
Click to expand...
You could check maximum number of pre-rendered frames for your scene. I think with max (3) you can ensure that what you see in VAM is what will more or less happen after rendering. Or, make sure that Timeline is using Game Time sync in settings (by default it's using Real Time sync). I don't know that scene, but perhaps breathing is done with Timeline (real time) and other stuff is not using it?
 
babul said:
You could check maximum number of pre-rendered frames for your scene. I think with max (3) you can ensure that what you see in VAM is what will more or less happen after rendering. Or, make sure that Timeline is using Game Time sync in settings (by default it's using Real Time sync). I don't know that scene, but perhaps breathing is done with Timeline (real time) and other stuff is not using it?
Click to expand...
Yup, guaranteed it's timeline needing to be set to gametime instead of realtime.
 
You must log in or register to reply here.

Similar threads

VamXFan
Assets VR180 Recorder Helper
2
Replies
27
Views
7K
ehowin
E
VRRGCD
Other BVH AnimAtion H & F
Replies
0
Views
889
VRRGCD
VRRGCD
Eyenstein
Plugins BVH Animations
Replies
4
Views
3K
Jocks3D
Jocks3D
Eyenstein
Plugins BVH Animations 2
Replies
0
Views
1K
Eyenstein
Eyenstein
hazmhox
Plugins Moan Recorder
Replies
12
Views
692
cyberbloney
cyberbloney
Back
Top Bottom