Results 1 to 6 of 6

Thread: lightwave 2019 VPR doen't render hypervoxel in previews.

  1. #1

    lightwave 2019 VPR doen't render hypervoxel in previews.

    Hello Lightwavers.
    I need to use the old legacy hypervoxels in sprite mode for a project (but i tried volume also) and wanted to see if the speed of the turbulence was ok. While I can see the HV in VPR, they won't render if I launch a preview.
    Anyone else?

  2. #2
    Registered User
    Join Date
    Jan 2005
    Location
    Colorado Springs
    Posts
    1,795
    This works for me in LW2019.0.3. Sample scene attached.

    Click image for larger version. 

Name:	HVs_VPRPreview_LW2019.0.3.jpg 
Views:	40 
Size:	1.07 MB 
ID:	145169

    Here are the Previews done with Perspective view and Camera view, saved as DirectShow AVI's and converted to MOV format with FFMPEG.

    HV_VPRPreviewTest_LW2019.0.3_Perspective.mov

    HV_VPRPreviewTest_LW2019.0.3_Camera.mov

    Good luck!
    mTp
    Attached Files Attached Files

  3. #3
    Thank you....mmmh... Weird. I exported and opened the scene with LW 2015 and I don't have any problem, only with 2019.
    Renderwise (F9/F10), the 3 Sprites emitters take about 8 minutes per frame in lw 2019 (legacy volumetrics) and less than 10 sec in LW 2015.

  4. #4
    RETROGRADER prometheus's Avatar
    Join Date
    Aug 2003
    Location
    sweden stockholm
    Posts
    15,096
    Quote Originally Posted by marchermitte View Post
    Thank you....mmmh... Weird. I exported and opened the scene with LW 2015 and I don't have any problem, only with 2019.
    Renderwise (F9/F10), the 3 Sprites emitters take about 8 minutes per frame in lw 2019 (legacy volumetrics) and less than 10 sec in LW 2015.


    2015 doesnīt have the new volumetrics, ergo the old "legacy" volumetrics hypervoxels3 will render it just fine since that is what was the current state of hypervoxels in 2015.

    For render times, there must be a setting in 2019 that is not equal to 2015 that makes it render longer in 2019, I do not think the sprites is slower by itself, uncheck radiosity GI and check AA settings in camera render settings.

    In fact, the old Legacy volumetrics renders pretty fast (volume mode) in 2019, especially overlapping hvīs from null items, in 2015 that would almost freeze the system when rendering, not anymore in 2015 even though
    the hypervoxels system 3.0 hasnīt been touched, so it is something with rendering in general.

  5. #5
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,505
    Quote Originally Posted by prometheus View Post
    In fact, the old Legacy volumetrics renders pretty fast (volume mode) in 2019, especially overlapping hvīs from null items, in 2015 that would almost freeze the system when rendering, not anymore in 2015 even though
    the hypervoxels system 3.0 hasnīt been touched, so it is something with rendering in general.
    Well, it's also plausible there was some kind of ray-marching problem in LW2015 that yielded the misbehavior, and was fixed at some point in LW2018 dev cycle (as opposed to it strictly being a perf improvement). It's easy to imagine how some kind of error in "merging" the hv datasets could lead to volume ray-marching issues, less obvious how every overlap could yield so many orders of magnitude more calculations to resolve that it resulted in "app-freezing" (yet correct) ray-marching. That always seemed a bit "off".
    Last edited by jwiede; 06-09-2019 at 04:09 PM.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  6. #6
    RETROGRADER prometheus's Avatar
    Join Date
    Aug 2003
    Location
    sweden stockholm
    Posts
    15,096
    Quote Originally Posted by jwiede View Post
    Well, it's also plausible there was some kind of ray-marching problem in LW2015 that yielded the misbehavior, and was fixed at some point in LW2018 dev cycle (as opposed to it strictly being a perf improvement). It's easy to imagine how some kind of error in "merging" the hv datasets could lead to volume ray-marching issues, less obvious how every overlap could yield so many orders of magnitude more calculations to resolve that it resulted in "app-freezing" (yet correct) ray-marching. That always seemed a bit "off".
    That is of course also what I suspected.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •