@panga said:
Yes I'm on Win7 64 bits SP1. But All liveCubes are not working. I have an error message saying that my graphic card is not compatible even if my system fulfil the requirements.
Hi Panga,
Can you visit the e-on Tech support page and enter a bug report on your issue with the Quadro 1800 graphics card. LumenRT should work fine with this card. Here's the link:
Very nice workin indeed Al. I'm still having issues re-directing error output to the log file. It seems as though Sketchup does not use stderr for error output. I've had some success just trapping messages in the Excpetion class StandardError but this is clumsy.
Hi Al,
Thanks - will do.
I'm trying to redirect $stderr to a file, but it doesn't work. $stdout works just fine but not $stderr. It appears that when Sketchup generates an error message, it does not call $stderr, but outputs to the console through some other mechanism. Anyone have any ideas on this.
Hi Everyone,
Here are some links to a few new LumenRT renders. I really like the softness and richness of the light in these:
Hi Ecuadorian. Very nice animation you made there.
@ecuadorian said:
Sounds fairly similar to LightUp so far, but with bounced light, better reflections, no artificial lights, and external instead of internal. After exporting, do you adjust settings/add objects or is everything set up before exporting? If you do alter some settings after export, how will changes to the SketchUp model be handled?
There are no adjustments after export into LumenRT. The process is entirely seamless. You just indicate the rendering quality you want ranging from draft (quick preview render taking under 1 minute), Review (~30 minutes or less), Final (~ 1 hour or less), Superior (~ 2 hours or more) and the type of atmosphere you want and then LumenRT takes care of the rest. There is no ability to add objects or new camera animation paths post export into LumenRT. If you need to change something on the model, you do it in Sketchup and then re-export into LumenRT.
@ecuadorian said:
I have to say it's fairly common for me to go beyond 600k edges/300k faces in models I've animated with LightUp, like this one. However, since LightUp uses a finite-element method (aka a grid) to solve illumination, I can't use it to create a walk-through of a 1Km x 1Km housing development, as I would need to use too wide a grid to show any light detail in close-ups. I only use LightUp for compact models. Seems like LumenRT, which seems to also be using a finite-element method, will be confined to similar compact projects (houses, restaurants, chapels), as so far the examples have been fairly small spaces. No house developments, no large shopping malls, no stadiums have been shown. I guess one would still need Lumion for larger projects. As it uses a screen-space effect, it can handle anything you throw at it and it can still look good on close examination, no matter the real-world dimensions of the project or if it has several million edges.
A couple of things here:
LumenRT does not use a grid/finite element method to calculate lighting. It can handle models of any physical size such as a 1km x 1km housing project. However, it will take much longer to render – perhaps several hours. The display of the final output will of course be totally interactive.
LumenRT was designed to be used as a collaborative tool for sharing design concepts, ideas, and models with your clients in a more immersive, interactive fashion. In other words, your clients will now have the ability to explore and navigate the models you create themselves, with very high quality lighting and fidelity. It’s not meant to replace tools like LightUp or Lumion or any other rendering tool that produces canned or fixed output. It’s really a complimentary tool or another “arrow in the quiver” to provide a way for you to engage with your clients in a more immersive, interactive fashion – to let your clients “play with” or “explore” the design.
The only thing you need to be mindful of when using LumenRT is that the interactive GPU performance is of course dependent on the capabilities of your client’s graphics card. Our tests have shown that for models with 500,000 polys or less, there is no performance issue at all provided you are using a reasonably modern graphics card. For your model shown in the link this one, this would probably exceed 500,000 polys and therefore experience some degradation in terms of FPS performance.
Hi there.
@ecuadorian said:
Thanks for the very informative reply, Dave.
A friend in another forum is asking whether this will be GPU-based. Based on your response, seems like pre-calculations are currently computed only on the CPU, while navigation will use mostly the GPU via OpenGL or DirectX, with the CPU handling real-time reflections and shadow maps. Am I correct?
Yes, this is correct the CPU computes what we call the LumenRT "Live Cube" and the the GPU displays it and allows you navigagte around the Live Cube.
@ecuadorian said:
I'm used to rather long pre-calculation times thanks to LightUp. Usually 35-40 minutes for a house like this one, using a 10cm mesh. However, Adam Billiard, its creator, has stated in LightUp's forum that he plans to move the pre-calcuations from the CPU to the GPU, using it as a "compute resource", "like Octane" (Maybe CUDA or OpenCL
). When this is implemented, there will be "no waiting", according to him. Do you plan to move LumenRT's pre-calculations to the GPU to reduce waiting times, as well?
It's possible. As GPU's and GPU software like CUDA/OpenCL become more powerful and more mainstream, the heavy graphics computing tasks will be offloaded to the GPU. I don't think we are quite there yet unless you own a very high-powered GPU cluster like an NVIDIA Tesla card setup.
@ecuadorian said:
Also, I guess a "LiveCube" (I'd prefer "pre-lit model" as "LiveCube" sounds like a simple panoramic still image) will reside in the GPU RAM, so the more complex the model and the finer the illumination mesh, the more GPU memory you'll need to be able to display it, right?
Yes, this is true. Most midrange graphics cards such as the the NVIDIA GeForce 460 can handle faily large models with 512 mb of graphics memory or more.
@ecuadorian said:
The need to pre-calculate and store this information will also mean there's a limit to the size and detail you can attain. If you want a bigger size, you'll need to lower the detail of the illumination solution.
Not really, it will just take a longer time to render (e.g. pre-compute). If you have a midrange GPU card it will handle most typical models just fine. If you include all kinds of fine modeling details with modeling polycounts above 500K or so, you may see some degradation in performance on the GPU side.
@ecuadorian said:
I also see no mention about a dynamic sun/sky/cloud system, object animation capabilities, or even an object library. These limitations would mean LumenRT will be directly competing with LightUp ($150) instead of Lumion (750€), so I hope you guys price it sensibly.
The first release of LumenRT will not include dynamic skies. Camera animation is done by exporting the Sketchup scene animation into LumenRT but there is no separate object animation system.
Hi everyone,
Dave Burdick from e-on Software here. We're pretty pumped up about LumenRT as it will be released soon. I thought I would jump in here and add my 2 cents to this very excellent post:
@ecuadorian said:
By examining the available info, this is what I either know or especulate so far:
LightUp: No need to export
Lumion: You have to export via Collada. Sometimes materials get all messed up on re-import in Lumion.
LumenRT: Seems to have its own SU exporter which then fires up LumenRT on a separate window.
Yes, LumenRT has a built-in custom Sketchup exporter which automatically exports the Sketchup model and then fires up the LumenRT renderer.
@ecuadorian said:
LightUp: Needs pre-processing time. Renders 720p video @ 3 fps with an average GPU. No speed gains from top GPUs.
Lumion: No pre-processing needed. Renders 720p video @ 0.3 fps with a nice GPU (GTX 570)
LumenRT: Needs pre-processing time. Renders 720p video @ 30 fps. Hardware to achieve this: Unknown.
LumenRT runs on any modern PC or Mac but rendering speed strongly depends on hardware. On my 4 core Intel 2.4ghz machine for example, a Review mode render (good enough for most cases) takes 15 minutes to an hour to render out a model depending on the size and complexity.
@ecuadorian said:
LightUp: Can use several cubemaps, called "irrcaches", for reflections.
Lumion: Can use only one cubemap for reflections. You can choose where to generate it if you want, or it can be generated from the camera's point of view.
LumenRT: Seems to be using either real-time raytracing or flat-mirror maps. Either way, it looks much better.
Yes, we compute real-time reflections.
@ecuadorian said:
LightUp: No actual bounced light calculations. Just pre-calculated AO with color bleeding.
Lumion: No actual bounced light calculations. Just SSAO with no color bleeding.
LumenRT: Seems to be pre-calculating bounced light with color bleeding.
Yes, that's correct.
@ecuadorian said:
LightUp: Can show direct light from emitters and point lights.
Lumion: Can not show direct light from emitters and point lights.
LumenRT: So far, no direct light from either emitters or point lights has been shown in the previews.
Yes, only the sun - no other light sources.
@ecuadorian said:
LightUp: Shadows are saved in the mesh.
Lumion: Uses shadow maps.
LumenRT: Seems to be using shadow maps, too.. or raytracing them in real time.
They are real-time shadow maps for increased accuracy.
@ecuadorian said:
LightUp: Can export a model you can freely explore in LightUp player format.
Lumion: Can't export a model in any way.
LumenRT: Can save an executable file you can give to a client. No need to install any player.
Yes
@d12dozr said:
I noticed that this latest version of the exporter (Version 1.1) places the pivot point of all groups and components at the origin of the global axes in the Sketchup model. When I open the file in Vue and try to swap out imported proxies as described here, all of the plants are placed on top of each other at the origin. (Please see attached pictures)
This bug is new to V 1.1 -- V 1.0 kept the pivot point of each component at the Component axes from Sketchup, which is the correct behavior. Its not a big deal for only a few plants, but if there are 20 or more precisely placed, then it becomes a problem.
Hi Marcus,
This is the way Vue has always handled imported objects. I will check on this and see if there is a fix.
Regards,
Dave
@starlex said:
Does this bug solved in SU2Vue Exporter? Using via .3ds or .obj export method it is impossible to use texture displacement on sketchup surfaces
It looks like your base model is too low poly for such high frequency displacement. Have you tried just using bump?
@bob james said:
Great news, Dave, but...
I've gone to my C3D account, but see no obvious way to download the update.
I did a search for SU to Vue and it led me to your post: the link on the post sent me to a page to buy it.Edit: My SU2Vue came as a part of the Vue 9 Complete Bundle - I didn't buy it separately: is that the problem?
Hi Bob,
There's a new update of Vue 9 complete coming out next week which should have the updated plugin as well. In the meantime, drop me an e-mail and I'll send you a copy of the plugin:
Hi Guys,
Shameless plug for City Engine Vue. This is amazing technology for creating entire cities procedurally. Plus, it's available at an incredible price of $299 ($199 for C-Club members). The technology normally sells for $500 to $5,000. Here's a quick render I did in Vue with City Engine:
@bob james said:
It's really strange: I have both Vue 8 Complete and Vue 9 Complete.
I can export from SU into V8C just fine, but the same model winds up being just a sphere in V9C.
It seems to me that there is a bug in V9C.
Hi Guys,
There indeed appears to be a problem with a speficif Vue 9 Complete build and importing .vob files. The build number is 9005403. We are looking into this and will most likely have a new build up soon to download.
Also, there is a new version of the SU to Vue Exporter 1.1 avaialble for download from your C3D account. It's a free update that fixes issues with large models and corrupt textures.
Dave
@chris fullmer said:
How does VUE set up its animations? With "keyframes" between camera locations, and then you apply a linear or bezeir transition? I do not know if you will be able to accurately recreate the camera path that SketchUp uses. But you could export the camera location at each frame, effectively makeing each frame a key frame with a linear transition betwen them.
The ruby API allows you to get the camera object for each frame of its animation. So I would guess that the best way to do what you're looking for is to have the user input the desired frame rate inside of SU, then export the camera location per frame to VUE and have VUE then set up the camera path frame by frame.
Chris
Thanks Chris. You confirmed what I thought. In Vue, you can create linear or curved animation paths. It appears that Sketchup uses some sort of arc-like movement when the camera is rotated around the scene. I like your idea of capturing intermediate key frames - I'll give this a try.
I'm trying to figure out exactly how Sketchup builds animation paths when moving from one scene tab to the next. It looks like some sort of spline or bezier path formulation is used. It's definitely not a linear path interpolation. Check out the link which shows a quick side-by-side comparison of a Sketchup animation (left) and the same animation in Vue (right). The Vue animation was constructed by taking the camera positions from each Sketchup scene tab and creating a linear animation between. Any thoughts or suggestions on trying to make the Vue animation match the Sketchup animation?
@thecravatman said:
Dave et al, Can you shed some light on my predicament. I have SU to Vue exporter, SU 8 and Vue 9 Complete. I load vob file from SU and it shows up in the layer pane and I can see the materials but I can see the scene. I select it and right click to select 'frame selected object' but can see anything. I re-scaled the model in case this was a mm to m problem but to no avail. I unchecked 'preserve size of elements at creation' check box again to no avail. I have tried via the python script.
This is so annoying as I can see that it has been imported, its just I can see or manipulate it. Any tricks? Thoughts or work around I have run out of ideas. I really need something like zoom extents or a positioning tool so that it fits in the scene where I want it.
Please tell me that I am missing something obvious.
Thanks T
Can you send me an e-mail and include a zip file containing the SU model. Send it to
dburdick@e-onsoftware.com
Not sure what is going here unless the scaling is causing problems.
@bob james said:
@krisidious said:
this has got to be some issue with Vue 9 can you go and install 8.5?
I have Vue 8 Complete and Automation -> Run Python Script works just fine as long as the exported model has no textures.
This is an improvement over Vue 9, but to have to "emasculate" all of my models and then re-texture them in Vue is not a viable workflowBesides that, this does not help with Vue 9
Hi Bob,
Sorry to see the problems you're having. Can you send me an e-mail to
dburdick@e-onsoftware.com with the model in a zip file so that I can take a look at it and see what the problem might be? It sounds like there might be corrupt texture file or something. There is a new update for the SU to Vue Plugin coming out later this week that might fix this problem.
@miikka1978 said:
Thanks for explaining dburdick. Anyway, it seems that there are many other faces with material on both sides in my crane model. But, export doesn't create "loose geometry" in these cases. Based on this, I believe that the problem arises when there is material on both sides of face and these materials are different.
Is there is any way/plugin to examine Sketchup models and geometries in order to find out if there are faces with different materials on the sides of the same face?
The SUVueExporter creates either:
double-sided faces - where the materials are the same on both sides or if one of the sides uses the default material
single-sided faces - where the face uses a different material on each side and neither of the sides is the default material
The reason for isolating the single-sided faces is that these faces are created as a single-sided mesh in Vue (e.g. where each polygon is treated as having a unique material on each side).
@miikka1978 said:
Has anybody experienced similar problem when using Sketchup models in Vue? I have exported my Sketchup model into Vue with the new plugin. But, when I move the model in Vue it is not complete component. There is separate SingleSidedFacesGroup that I have not created in Sketchup.
You have to move the model as a whole. The single sided faces group consists of all of the faces which have materials on both sides. If you just grab the whole model and move it, all of the sub-components will move with it -- including the single-sided faces group.
@d12dozr said:
I asked this on the Cornucopia forum but no response yet over there...
I'm having some trouble, hopefully just beginner's ignorance...
My Sketchup scenes are not translating to Vue cameras. I made sure to unlock the camera height and uncheck "Sun face camera" in Vue like the Sketchup2Vue manual says. I am opening the model in Vue using the Python loader script.
the imported model comes in partially below the ground in Vue, even though it is above ground in Sketchup.
I'm using Vue 8 Complete and SU 8 free for the Vue export.
We discovered the problem on this one. In Vue, go to Options-->General Preferences and then uncheck "Preserve size of natural elements at creation"
This is a legacy option that auto-adjusts scaling to Vue Units on imports. It should be off by default, but apparently on Vue 8 it's on - so just uncheck this.
