Interesting experiments indeed! For early results they are promising. This is no substitute for real volumetric clouds of course, but you don't always need that, and of course the render times for this are much nicer too. Definitely keep us updated! Of course the frustrating thing about this is, if it's as easy as you describe to do this, why didn't E-On ship with some cloud ecosystem examples and presets? It seems like the least they could do to alleviate the conspicuous lack of real volumetric clouds. Btw Vue is largely fractal-based too. Terrains (procedural in particular), any procedural materials, etc. could be termed "fractal based", as much as Terragen is anyway. - Oshyan

Message edited on: 09/17/2005 16:26

Great info and tests. One comment however is that, with such low average render times on most machines, particularly the Opteron, the overhead of simple file I/O, frame switching, etc. may be skewing the results. In other words if rendering a frame takes an average of 3 seconds, and the combination of file I/O, frame switching, etc. adds an overhead of even 1 second (which is more than likely), a full 1/4 of your "render time" is composed of non-render operations! The nice thing about this is that, while render time scales with frame resolution and scene complexity, overhead will tend to remain roughly the same (probably increasing slightly with complex scenes). So basically what you want is to increase the ratio of render time to overhead so that overhead comprises a much smaller percentage of your total render time, and thus you get a more meaningful idea of how much extra machines will really help performance. I suggest individual frame render times of 30 seconds to 1 minute on your median machine for best results. The results may not turn out significantly different, but it's worth the try. - Oshyan

If these programs would just support a few of the major coordinate systems (Geographic, UTM, etc.) then any existing georeferenced data could be used easily, and no manual matching or 3rd party terrain/overlay combinations would be needed. You could download data directly from the source and as long as it was already georeferenced (as most GIS data is), it would align properly, at least to the limits of the georeferencing accuracy. Programs like 3DEM and Global Mapper already do this, of course. And while these are considered GIS features, with the increasing interest from users of programs like Vue and Terragen in realistically depicting natural places, and the widespread free public availability of this kind of GIS data, it seems only logical for these software programs to at least be able to read (if not edit) GIS formats and their embedded georeferencing. Allowing this would save everyone a lot of work. - Oshyan

If vertical scaling is the only reason you're using bitmap conversion - which inherently loses the proper scaling of the terrain anyway - then why not just rescale in Vue? Neither method is apparently giving you the correct scale (although Vue should be drawing correct scaling from a DEM import as that data is included, unlike a bitmap import), so I don't see why either has advantages in that regard, except that apparently bitmap import just has a lower scale by default, which I guess looks more correct to you. But again I don't see why you couldn't just scale it in Vue, and save the loss of accuracy. - Oshyan

Yeah Vue badly needs a more widely supported 16 bit import format. Have you tried using Vue's DEM import and exporting from MicroDEM or 3DEM into said format? That ought to maintain better accuracy. Quite frankly 1/9 data is kind of useless to work with if you're going to be exporting to an 8 bit format. The additional detail will be lost. - Oshyan

A dual core, dual Opteron system is overkill for most people. An Athlon 64 X2 will be a lot cheaper, and still give you great performance. And if you really need the additional rendering speed, you'd get better "bang for your buck" buying a "tricked out" X2 machine for your primary system, and then buying several more "bare bones" render-only systems to use as Render Cows. You could get 2-3 X2 systems, in addition to your 1 tricked out X2, all for the price of a single dual core dual Opteron workstation. All modern graphics cards support OpenGL "in hardware". The difference between the high end cards and the "gamer" cards is not as much as you'd think. 90% of the time they're based on the exact same chips. The differences are either in drivers (yes, just the drivers - Pro card drivers are optimized for stability and OpenGL viewport performance as opposed to games and raw speed), or small (but important) hardware features are turned on or off for respective versions. Sometimes both of these methods are used. This is why some people can often turn a non-pro card into a pro-level one, or a lower-end pro card into a higher end one. The pro cards also go through more stringent QA, and tend to be clocked more conservatively, so there are some qualitative differences which may show up in the end user experience, depending on the application. Generally speaking only high end 3D apps like Maya or Softimage really benefit from a Pro card. To my knowledge there is no conclusive or even anecdotal proof that Vue in particular runs better on Pro cards. Anyone have any experience with this? Bottom line: unless you really have just way too much money to spend, go for an X2 with some render slaves as needed, and don't bother with a high end Pro card. Maybe ask E-On for a recommended graphics card configuration and buy that, if anything. But any newer card from ATI or Nvidia should be fine. - Oshyan

The response time on the Samsung is an abysmal 25ms though. My roommate has a 16ms and even on that I see noticeable (and irritating) ghosting. This is most noticeable when watching movies or playing games, but even in regular use it can get annoying. And you can get a 24" widescreen CRT with higher resolution for less than half the $1600 cost of the LCD. The LCD has the advantage in power use, weight, and size by far, but the CRT will still have advantages in viewing angle, color accuracy, etc. LCD technology is also, at present, totally incapable of producing a true black because there is always light leakage and they use a backlight. Rather than lighting only the active/colored pixels, it lights the whole LCD uniformly and "black" pixels are closed to light. Full coverage is impossible with current technology so there is leakage and you get more like a dark grey in areas that should be black. This is particularly noticeable in a dark room. So I think a declaration of the current supremacy of LCD's is a bit premature. - Oshyan

Yeah, I'm familiar with Taiki. Frankly volumetric clouds are something of a passion of mine, since - as I said before - I consider them vital to realism. Unfortunately I'm not a Lightwave user, and don't have the money nor free time to invest in purchasing and getting to know it just to use it as a landscape renderer. Although I have no doubt if I did so it would be great at it (I've seen some fantastic results come out of it). As far as other volumetric solutions, there are of course many. One I find especiallyinteresting, due in part to the particular approach used and the apparently high quality results, combined with the claim of being faster than other methods, is implemented in POVRay. Take a look: http://www.oyonale.com/ressources/english/sources13.htm Render times seem to vary between reasonable and outlandish, although they're quoted for a machine far below top-end today. So something like this might be worth experimenting with, either in Lightwave or, ideally, in Vue (could this be done through Python?). I'll keep an eye out for the shader geniuses making magic out of Vue's volumetrics. I'd love to see it, so come on guys! - Oshyan

Thanks nano, you said all very well and I agree 100%. Although my first message did mention Vue's feature list, etc. this was primarily to show why I was looking for the feature that I was asking about. Clearly if Vue did not say "volumetric clouds" in their feature list, I should not expect it. But since they do, and I can't figure out how to use them, as was the case, I figured a Vue forum would be the best place to ask. ;) I also apologize if this question has been answered before. My original messages, that were then swallowed by Rendo (because I tend to write long posts, the PHP session times out I guess), actually included a bit of history about my interest in Vue and that might have helped understand my position better. Long story short I have only been seriously interested in Vue since version 5, and particularly Infinite. So I have only been spending much time here in the Vue forums on Rendo since V5's release, and more so with V5I. If I missed an earlier thread about this very subject, that would be why. I did do a search before posting, but Rendo's forum search feature is not the best IMO and it didn't yield any meaningful results in the first few pages. In any case it's good to get a definitive answer about this, even though it's not the one I was looking for. I will continue to hope for better clouds in the Vue 6 engine, hopefully next year, and meanwhile I hope some Python or materials genius comes up with a way to make a decent approximation with the existing systems. :) - Oshyan

It's not really to do with how "infinite" it is, but more with how easy it is to generate a whole sky full of realistic, varied, volumetric clouds. It just so happens that cloudscapes in real life are, for all intents and purposes, often "infinite". Certainly there are times when you only want one or a few clouds, but in my area at least these will be the exception to the rule. We get a lot of thick, low-level cloud here, and so naturally I'm wanting to duplicate my environment as part of my enjoyment of natural landscape rendering. Now producing this effect may be possible with ecosystems, and I'm certainly trying to go that route, but to me "clouds" are a feature, especially since E-On lists them as such. So what I mean and expect is that there be a cloud function that allows a quick and easy setup for volumetric clouds, much like the existing cloud system works, except for true volumetric clouds (such as are apparently possible using object primitives). Their current approach is akin to listing "thousands of cloud types" as a feature, but then requiring you to manually setup a 2d infinite plane and configure a texture from scratch to act as your clouds. Are you glad you don't have to do that every time you want some clouds? That there are presets for many good cloud types (albeit none truly volumetric)? Well, none of that is currently available for volumetric clouds. And considering that, in reality, all clouds are "volumetric" (have volume), that seems like a pretty big oversight. If they're going to advertise the feature but rely on some complicated, trial and error method of getting the results they advertised, they ought instead to at least give us a little automated help or simply not list "volumetric clouds". Put in a "volumetric cloud" object, just like the regular cloud plane objects they have now. Make it out of an ecosystem and an object primitive, I don't care as long as it works, but having to set it up manually means the "feature", as listed on Vue's feature list, isn't there. It doesn't seem like this would be a difficult thing to provide. Your comments re: Terragen make me feel like you think I'm just here to bash Vue. I most certainly am not! Frankly that comment makes me feel a bit unwelcome, and I don't think that's fair. If I've read into what you said though, I apologize. I've been working with landscape rendering software for over 10 years now, starting with VistaPro, then moving on to Bryce, World Builder, and now have been with Terragen for some time. I stuck with Terragen so long because of the great atmospherics, despite its other major shortcomings (which I fully recognize). So far IMO no other application has been able to best TG's realistic atmospherics, despite its limitations in terms of a single cloud layer and limited cloud types. But I wish that weren't the case! I would love to be able to work in an application with so much more flexibility and power like Vue. But I have my particular needs for a landscape renderer, and unfortunately it seems like Vue does not fully address them. I consider myself a pretty fair, even-handed person, and I think my long experience with multiple landscape renderers contributes to that. I am interested in landscape rendering as an art form and hobby in itself, not ultimately in any particular application. In fact I have been a tester for several other landscape rendering applications, including MojoWorld. The fact that one of them has fulfilled my needs recently more than others is only the fault of the developers. If I could decide what features each dev put in, believe me I would! So please don't assign a bias to me just because my current choice of programs is different than yours. If anything, my needs as an artist and hobbyist create any biases I have. And I certainly hope you wouldn't hold those kinds of preferences against anyone. I'm here because I am hoping that another program may finally be able to meet those needs, and I'm asking fair and unbiased questions trying to make a reasonable and full evaluation. If I had no real interest in Vue, I wouldn't be here. - Oshyan

Wabe, the reason I'm focusing on the cloud aspect of "volumetric" is because E-On lists it specifically as a feature. From the V5I feature list: "Volumetric clouds, lights, materials (visible rays, with optional dust)." If they had just said "volumetric materials", I would not be surprised that in order to get volumetric clouds you have to use object primitives with volumeteric materials. But in fact this "volumetreic clouds" feature does exist in the V5I package. You can turn the cloud material in a cloud plane/object into a volumetric materal, and many of the preset volumetric atmospheres have this setup, so it seems clear this is an intended use. It's just that there's nothing volumetric about the results as far as I can tell. So unless anyone has information to the contrary, I consider the feature list misleading. And that is a bit disappointing, especially considering V5I is otherwise so promising. Not everyone will find this particular feature important, but to me it is vital to realism, so it's just about a deal breaker. I'll continue to play with the demo as E-On kindly allows a generous 60 day test period, but I'm afraid that, unless I discover some hidden and dramatic realism booster for atmospheres, I'll have to hope instead that TG2's instancing system lives up to the power, flexibility and ease of use of Vue's, or that V6I with true volumetric clouds and improved atmospherics comes out by the time TG2 is released in 2006. Thanks for the info everyone. :) - Oshyan

Thanks Wabe. I believe I had seen that thread though, and as I said the method of using spheres (or other primitives) with volumetric materials is less than ideal. The results are better than the standard clouds, but still not particularly realistic, and the question of whether they react properly to light is also a big one. Besides, this hardly qualifies as "Volumetric Clouds" as listed on E-On's feature list (separate from volumetric materials I should add). So I ask again, is E-On basically using the word "volumetric" in some other sense than I understand it, or is there really a way to make volumetric clouds using the actual cloud system? - Oshyan

A photo on a billboard doesn't solve the issue at all. If one would like to be able to see a cloud from any angle as they move their camera around, even through or above it, a 2D photo is even worse than the regular cloud system. ;) It's partly a matter of quality, yes, but the major thing is I'm confused about "volumetric clouds" being on their feature list, yet not being able to figure out how to use/create them.

Not only that but, despite workarounds such as you describe in another post, billboards just don't emit proper lighting and matching lighting, atmospherics, etc. with a billboard is difficult. Even worse, you can't change the lighting on anything in the photo, so you have to either tailor your scene for a photo you have, or try to find the perfect photo to match your scene. Thanks for the reply though, any input is appreciated. :)

• Oshyan

Message edited on: 07/19/2005 21:44

Attached Link: Pentium 4 Hyperthreading explanations and discussion.

Samhain, those are all 8bit/channel images, meaning there are only 256 possible different levels of height. This makes for large potential inaccuracies and possible "stairstepping" in your terrains. They have also been .jpg compressed, which adds artifacts and destroys some fine details that are much more important in a heightfield than in a regular image. That resource is alright for casual use, I suppose, but if you really want to depict an actual place, I strongly recommend against it, as the results will have a high potential for inaccuracy. - Oshyan