Posts by landrvr1

    It isn't. Turn the camera 90 degrees in the pano.

    Okay, you're correct! I must have uploaded the wrong pano. The camera is off by about 36" or so....


    However, my mistake actually proves my point even better.


    Here's a side by side of the initial view. Even though the camera in the Enscape shot is further back towards the curtains, the distance from the far curtain wall actually increases. The only way that happens is if the native FOV in the Enscape image is way off. There's no other explanation.



    I'm not disagreeing that the viewer can play a part in correcting this issue. However, adjustments on the viewer side only zooms the native image and it's quite apparent when looking around that the movement takes on the feeling of panning around the image. The more you have to zoom in to correct an FOV, the worse that effect.


    BTW, Focal Length has been an adjustable setting in V-Ray physical cameras since their introduction. The entire idea is to virtually recreate every aspect of a real camera. It's an absolutely valid use of the term in the 3D world.

    Also, I would encourage others to try the same experiment with V-Ray or any other engine that allows control over the camera FOV. If memory serves (and it's been awhile) I actually recreated the Encape distortion quite easily in the V-Ray created image by simply increasing the FOV and dumping the image into Yulio.

    Respectfully disagree. The camera for my examples was in the exact same location (created a point in Max where the camera was located and imported that via FBX into SketchUp, which I then used to set the camera location), and this is not purely a viewer issue by any means.


    The main problem still originates with the totally unrealistic FOV default in the Encape camera when creating a pano. The examples I originally posted speak for themselves, as they clearly demonstrate - without any adjustment on the part of the Yulio viewer - the differences in the original images.


    In fact, Yulio - like many automated viewer apps - gives you zero control over the software FOV unless you manually use your scroll button to 'zoom' the viewer image.

    Thought I'd take a moment and explain something if I may:


    Every camera - whether virtual or real - needs to establish a focal length/field of view. This is no different with a 360° image. Otherwise, you'd have no image, lol!


    I use the term FIELD OF VIEW in these cases because that's what 3D software such as V-Ray or Enscape typically use. Another term could be FOCAL LENGTH. While the two are distinct elements in the world of film and photography, they are connected and basically arrive at the same result:


    In conventional photography, whereby you are creating a full 360° pano image and stiching the shots together, a longer focal length/lower Field of View will bring objects CLOSER to the camera but require more stitching -because you've generated more still photos. With a 360° lens - or a render engine - what's happening with a longer focal length/lower field of view is that the same amount of visual data is present in the image, but the final output looks much more distorted (until it's unpacked in a viewer).


    When creating a pano, the Enscape camera is set to a to a very short focal length/higher FoV. In V-Ray and other engines, you can control this for the final output.



    Still waiting on this fix, by the way. ^^

    Okay, rolled back to Enscape version 3.2.0+65063 and the problem was fixed.


    I've now cross-checked on two other computers running vastly different graphics cards/drivers/versions and this appears to be a bug.


    Adam, find anything interesting?


    EDIT: Just reinstalled the latest NVIDIA driver (516.59) and everything still works.

    Attaching the SketchUp File. Thanks Adam.

    test.zip


    Just tried the latest version 3.3.2+82281. Same problem.

    Tested on a basic Dell laptop that's running Enscape version: 3.3.1 +75071 and a standard, NON-RTX card. Same problem.

    Rolling back the NVIDIA driver did nothing.

    Testing previous Enscape versions now.

    Experiencing an issue lately in which certain self-illuminated materials are becoming highly pixelated.

    The problem seems to be with jpg textures that have fairly strong RGB values.

    Images that are more muted or 100% desaturated aren't exhibiting the problem.


    Textures are RGB 8-bit jpgs.

    Using png files does not help.

    Changing to CMYK does reduce the severity, but there's still issues.


    I'm running an RTX8000

    NVIDIA driver up to date: 516.59
    Enscape version: 3.3.1 +75071

    I'm probably going to roll-back my NVIDIA driver to see if that helps.


    Anyone else having any issues?

    The problem is that if items are stored on the C drive of the student's computer, the path will always incorporate their unique username in Windows 10!
    With other drives that's not a problem.

    I created a different login account on my new computer that had the same username as the computer I had with my former employer. This solution worked great, you just have to make sure that you set access permissions properly across multiple users when setting up the new account. Of course, depending on IT policy, it may not be possible for a student to set up their own username on a school machine.

    That's clearly a serious of individual panels, raised from the substrate material at different heights. I'd make a flat substrate panel and give it a brass material, then quickly model those squares and rectangles in SketchUp and lay them on top. Would take no time at all!

    After seeing a recent thread I finally did a test using the excellent Keyframe Animation extension. Works pretty well and it's easy to use. I'd actually tried this a few Enscape versions back, but could never get it to work!

    Watch Video


    243 frames of animation, at 30 frames per second. 8 seconds of animation.


    Rendertime with my RTX8000 was about 25 seconds per frame - much longer than simply rendering a single frame without animation - but still pretty quick. Total time to render the sequence was around 101 minutes.


    I should mention that this is a pretty large scene. Tons of polygons, lots of textures, and loads of Enscape proxies. The film only shows a fraction of what's there, so this was a pretty good test in terms of a big pull on the GPU.


    The best workflow I've found so far is to first create your Scenes within the Enscape View Manager. My test had 9 initial scenes, and for each one I'd move the camera forward just a bit, then make a new scene. Move forward, make a new scene. Best to have the Sync View on in the Enscape menu. (watch the Keyframe Animation tutorials for a better understanding of what 'initial Scenes' are...)


    Once I had my 9 initial scenes, I opened each scene one at a time in SketchUp, moved an object, then recorded that movement in Keyframe Animation.


    There's some important things to keep in mind, and they took me a bit to figure out:


    Every scene, regardless of whether your camera is moving or stationary, will need the Camera Location box checked in SketchUp. If you have a scene in which that cam data isn't captured, the rendered output will be ALL BLACK.


    Also, just as important: every SketchUp scene that you initially create (before the Tween Scene creation step) MUST have an object moving and that movement needs to be recorded by Keyframe Animation. I had two Scenes where the cam continues to move forward but I didn't want any animation. When you go to create all your Tween Scenes, they won't be generated for any sequence that doesn't have an object moving because - technically - nothing is happening. I got around this by animated a simple box out of the camera view for those two Scenes.


    I did this very quickly just as a proof of concept, so it's a bit rough. I'd like to get a softer landing (easy ease) for each chair, so I'll try going into my original file (again, 9 scenes) and add an additional scene for each object just before it touches the ground (12 inches or so). You can then set the duration of the animated movement for that scene, and start to get a sense of ease in/ease out. For instance, if each chair takes about 1 second to drop, the last 12 inches could be set to take 2 seconds or so. Nothing crazy, because real ease in/ease out isn't possible. The timing settings in the Extension look to be pretty great.


    There's real potential for this extension, but it will take a bit of patience and practice.



    Link to extension:

    http://regular-polygon.com/keyframe-animation/

    There's some must-watch tutorials on the site, and a nice user guide as well. I definitely plan on buying the license.

    You could also make 3 or 4 different short clips - each with a different color but the same camera movement. Each clip would stack directly on top of one another, and you'd keyframe a fade effect from one clip/color to the next. You could also then use a colored spot light to cast more color under your skywalk...

    Auto updating proxies is a pretty inconsistent feature. I've noticed that the larger the scene, the less likely the auto update will work. The only consist pattern I've seen is that auto updating will sometimes work for a short time after recently opening the file and firing-up Enscape. The longer I work in the file, the more likely auto update will not function!

    Having a new update button would be super handy. Relaunching Enscape from scratch, with large scenes, is a hassle for sure.

    3.1 is way too visually glitchy for me. Going back to 3.

    Couldn't even run with DLSS turned on because of the ghosting (already reported), and very odd effects on my PNG background edges (especially trees) whenever I'd start moving.


    No matter what the settings combo, there's massive flickering that occurs on glass reflections from light fixture sources when inside a space. For instance, rows of linear light lenses within an office space (white with some self illumination) flicker madly on the exterior glass when moving around the space.

    My NVIDIA driver is current.