Hi LMcLean, We may consider a gallery some time in the future. For now people can always post images as attachments directly in message posts. We could create a separate forum area specifically for imaging posting and not have to bother with integrating a gallery system since galleries are not the real purpose of the project. An image without a good amount of accompanying text is not very useful in this context. I do hope that people post images frequently to illustrate their points, and will consider a separate gallery forum for this purpose. Thanks! - Oshyan

Reflectance is relative to angle for almost all surfaces (in real life anyway). So for any surface with any amount of reflectivity you will always see different amounts of reflected light depending on your angle of view, which will change across a camera lens for example. So, with a single light source, you will always have a varying amount of light across your scene simply due to angle of reflectance. You could try remedying that with several light sources to get a more flat lighting setup. Using an Orthographic Camera might be another solution. Not sure if Vue has such an option, but the top-down camera might be in orthographic mode. - Oshyan

Photorealistic, perhaps not. But it looks pretty good to me. Just depends on the lighting and the particular cactus.

However, while the cactus is pretty realistic, I'm not so sure about the ground.

• Oshyan

You will not get 1600x1200 or above in anything less than a 20" LCD. If high resolution is vitally important to you, then yes you will need to get a larger LCD. The thing is that the actual pixel density doesn't increase much. You simply get the same density with a larger screen area, and therefore "higher resolution". The resolution of the unit taken as a while is higher, and so yes you can display more "virtual area" on your screen as a result, but you will not (for example) see finer detail, and pixels will not be less noticeable (in contrast with high resolution CRT's which can go up to 2048x1536 in 21" size, where you will see finer detail). The other thing to keep in mind with larger size LCD's is that the response time is typically lower than with smaller ones. The larger LCD's usually get technology innovations later than the smaller ones as generally speaking it is easier and cheaper to introduce new advances on smaller systems. The response time can definitely be an issue if you are a gamer and sometimes also for watching movies, or anything else with fast motion. My roommate has an LCD with a 12ms response time and as an avid gamer he finds it to be a bit too slow, with some noticeable ghosting. I think 8ms might be acceptable, but possibly even lower would be needed. Unfortunately the quoted manufacturer response times are also not always "accurate", or at least not all measured in the same way, so you may want to read the in-depth reviews at a site like http://www.tomshardware.com/ to get more realistic numbers. 19"-21" is probably the "sweet spot" for LCD's at this point. You get the best price-to-size ratio at 17", but 19" is close enough that it's worth the jump. Anything larger and you start to run into seriously escalating costs. Generally you will be limited to 1280x1024 on a 19" LCD, so if that simply isn't high enough for you, you will have to go larger. I still wouldn't recommend larger than 23" though. At 23" you start to be able to do 1920x1200, and that's really about the limit for desktop-oriented LCD's. Anything larger and you probably wouldn't want it on your desk. Apple's 30" "cinema" display notwithstanding. ;) Even that only does 2560x1600, which is larger in the width only because it is a widescreen monitor. Eventually LCD's, or a similar "flat/thin" technology, will be competitive for color critical work. In fact there are advances going on right now that make LCD's far more color-accurate and give LCD's much higher dynamic and contrast range than CRT's (HDR LCD's). However for the moment most LCD's are definitely sorely lacking in color reproduction. They can't reproduce a true black - period - (it's always a sort of gray) and the viewing angle issues mean that even if you're viewing square on, there is some amount of color, contrast, and brightness distortion at the edges of the screen (LCD users: you may not notice it, but it's there and measurable!). So yeah, if absolute color accuracy is vital (usually this is for print work - web work usually can't assume color accuracy because of the variability in people's home displays!), then an LCD is not a good idea at the moment. But otherwise, provided you are aware of the issues (no true black, potential response-time issues if you're a gamer, and viewing angle issues), and you buy a quality LCD, you should enjoy the benefits of lower desk-space usage, lower emissions, and lower power use. But I for one won't be buying an LCD for my main system any time soon. - Oshyan

In my experience as a computer support professional, SP2 does "cause" issues, but in 99% of cases it's because a problem existed before but was not evident, or not as serious. So if anything SP2 tends to magnify problems or bring them to the surface, but the problems are usually there to begin with. PSU's without enough power, heat issues, questionable RAM quality, overclocking, unnecessary resident programs, etc. I run SP2 without problem on all 5 of my home systems, and the customer's systems I've run into issues with have all proved to have underlying problems. Although you could say "If it aint broke, don't fix it", in many of the cases it seems more like a blessing to be made aware of the problem earlier so it can be addressed. Better to take care of a potential issue now than be caught out by it later. Just my 2 cents though. - Oshyan

You have a very active imagination Veritas. :D

• Oshyan

Message edited on: 11/02/2005 15:26

I didn't say "networked code is harder to write than multithreaded code". I said "...networked multithreaded code...". That's a key difference. It's easy as pie to render two concurrent frames on the same machine with dual CPU's/cores, or on separate machines by manually launching the processes. But even in that case, when the "effort" is not really in the code and not programmed specifically into the application, it's still easier to do on a single machine than over the network. But rendering something like a single frame across a network (which is equivalent to what you're generally talking about when a renderer is locally multithreaded) is much harder. So when I say it's harder to write networked multithreading code I'm talking about A: rendering applications specifically - including networked web apps is completely meaningless as the methods of doing work are essentially different, with seriously different demands. And B: utilizing the same methods. In other words rendering a single frame on a single machine with 2 processors/cores is a lot easier to accomplish than doing the same over a network. Rendering multiple frames concurrently is similarly easier locally than remotely. The only time it's easier to write networked code would be if you're comparing rendering of a single frame with rendering of multiple frames (single frame on the multicore CPU, multiple across the render farm). But that's comparing apples to oranges. Most major rendering engines have been multithreaded for ages, but comparatively few include actual facility for network rendering of a single frame. As for dedicated render boxes vs. one bigger all around machine, having done a significant amount of benchmarking myself I can tell you that e-mail, web apps, etc. impact rendering applications very insignificantly. Perhaps a few percent at most, amounting to perhaps an hour or two lost over several days of rendering. I think I made it clear that there is no doubt a render farm will accomplish more work for less money. I certainly don't argue that. But if your current machine needs upgrading anyway, it makes more sense to get a nice main machine and later get a bunch of network boxes. It seemed like the original poster was already interested in a new machine. People should also be aware of the space and power issues involved in having a render farm. I think you can all imagine, even with small cases, how much space several machines would take up. And power can be a problem too. Around here a kilowatt of power use costs upwards of 20 cents per hour. If you have 5 machines, which will run at an average of 150 watts or so even with smaller PSU's, you're running 750 watts of power, and if you're using it consistendly that's over 500kw of power use per month, or translated into local power costs over $100/mo. That being said if you're serious about rendering, especially if this is part of how you make a living, there is no method more cost-effective than a bunch of cheap render boxes. So bottom line I think we're in agreement here. ;) - Oshyan

HT is really just a way of taking advantage of otherwise "lost" CPU cycles due to pipeline bubbles and stalls, which are more prevalent on the P4 architecture due to its extremely long instruction pipeline and thus higher branch misprediction, etc. penalty. People often wonder why AMD hasn't implemented an HT unit and the answer is it wouldn't do much good, AMD CPU's tend to be running "flat out" more of the time because they're more efficiently architected. Generally this seems like a plus, but when you're multitasking the HT approach is a boon. Now that we have dual core I think it will be phased out, especially as Intel moves to CPU's based on their Pentium M mobile core, which itself is much more efficient (and shorter pipelined) than the P4.

In any case, because HT is just "taking up the slack" and is nowhere near the equal of a full 2nd CPU, it can never get much more than 20% of additional performance, unless the CPU was severely underutilized by the application in question without HT. This is the case in Terragen for example, where 2 TG threads on an HT P4 can net up to 60% performance increase - but this is the exception to the rule by far. And the trade-off in that case anyway is that a single Terragen thread runs abotu 25% slower than an equivalent Athlon system.

It is easier to wrote local multithreaded code than it is to write networked multicoded thread. This is for the obvious reason that local multithreading does not need to deal with the overhead and unreliability of networking and its other issues. In other words utilizing a local dual core or dual processor machine will be easier and more efficient than utilizing a networked farm of multiple machines of equivalent power. That being said the farm solution would generally be cheaper, as has been said.

As far as memory limitations, most rendering is not particularly memory bound. You can see in rendering benchmarks like http://blanos.com/benchmark/ http://www.tabsnet.com/ and http://tgbench.kk3d.de that similar machines with different memory speeds and sizes do not tend to make a significant difference. Rendering spends far more in CPU execution time than it does in transferring large amounts of data around (this is unlike gaming which tends to require a lot more data transfer).

You're also contending with the memory limits of the operating system, especially on the PC side. If you have 3GB of RAM, you can assume 1GB is dedicated to the OS and the other 2 to your application. Having more memory wouldn't help because the application can only use 2GB max on a non-64 bit Windows system. And let's not forget Vue isn't 64 bit yet anyway.

Also keep in mind that running a multithreaded application locally is more efficient memory-wise because the scene is already in memory - both threads can access the same memory pool. It's not like each thread has to separately load the entire scene or anything. So let's say you have a scene that requires a full 2GB of RAM - would it be more cost-effective to buy 3GB of RAM for a dual core system and multithread locally, or buy 3GB of RAM for two separate machines and do a network render? The answer, of course, is the single dual core machine. This starts getting less attractive as an option when you start looking at Opteron's or other high end CPU's of course, but now that there are mainstream dual core CPU's this isn't really necessary.

Also don't forget the power and space needs of a renderfarm solution. A single dual core machine will still have about half the power needs of two single core machines, and of course exactly half the space needs. :D

So to get back around to the original point, I'd personally recommend an Athlon X2 system right now. I'd recommend going for the highest clocked version you can, but don't worry too much about the cache size. For example you can get the Athlon 64 X2 4200+ at 2.2Ghz with 2x512KB cache (1 for each core) for $470 and the 4400+ with 2x1MB cache for $530 - $60 more. The 4400+ has larger caches, but in most applications that will not translate into a significant performance increase, so go for the 4200+. It's probably the best price/performance ratio for the X2's right now anyway, although the 4600+ at 2.4Ghz is tempting. Also note the 3800+ at 2.0Ghz and $347 is actually less than 2x the cost of a normal 2.0Ghz Athlon 64, the 3200+ at $190. That means you're no longer paying a premium for dual core, in fact it's more cost-effective (just as it should be). That is not counting the fact that you don't need to buy a 2nd case, CD/DVD-ROM, hard drive, memory, etc. Shared memory is only an issue if you're running 2 different applications, or the application you're running is not properly multithreaded. But if you do plan on multitasking with memory-intensive applications a lot, definitely go for as much memory as you can.

So the short answer: get an Athlon 64 X2 system with 3+GB of RAM. You'll be king of the block. :D If you don't want build it yourself (the cheapest and most versatile approach), these guys will build you a sweet machine on the cheap: http://www.monarchcomputer.com/ Save some money over Alienware, etc. ;)

• Oshyan

Message edited on: 10/19/2005 16:29

Message edited on: 10/19/2005 16:30

Attached Link: Terragen 2 Alpha image gallery.

As the author of the first image I can say yes, it is 100% Terragen. No post work. And thanks for the compliments. :) Clearly, if you look at the full gallery (see attached link), this is one of TG2's major strengths right now. You can also expect clouds and overall atmospherics to improve even further by the time TG2 is released. Once we can show object stuff you can judge for yourself how that stacks up to Vue. An instancing system like the Ecosystems will be included, but from my experience with the demo of Vue 5I I can say it will be tough to beat. I have confidence in Planetside and I think they will do a good job, but only time will tell if it is as powerful and versatile as the Ecosystems. The main concern at this point is that there is no announced release date. TG2 was originally due in 2005, around now, or perhaps a couple months ago. The last word on a new release date was "some time in 2006". Fortunately there will be a "public beta" later this year (2005), and you will probably all be able to try it out. So you can see for yourself what it has to offer. :) I think Vue is a great tool, but for me it has always been atmospherics that really set landscape programs apart. That's why I've stuck with Terragen for many years, even though it doesn't support objects and most of the other programs do. I've missed the ability to add things into my scenes, especially vegetation, but the beauty I feel I can get out of Terragen is still unmatched (for me) by any other program, vegetation or not. Of course the types of scenes I can do are very limited. ;) Anyway I think in the end it's very possible TG2 and Vue will be able to coexist well in a person's production pipeline. TG2 will clearly be good at atmospherics, and hopefully at vegetation and instancing (although they've already made it clear that no built-in procedural vegetation will be included). But Vue is very versatile in its object handling capabilities and with Fusion it will also have much closer integration with other 3D packages than Planetside has indicated will be the case with TG2. TG2 should have good import/export support, but as far as is known thus far it will not have advanced connection plugins like Fusion. So Vue's built-in vegetation and other object handling and integration may match up well with TG2's own strengths. We'll see... See the TG2 FAQ for more info if interested: http://planetside.co.uk/terragen/tgd/tg2faq.shtml Btw HDR output from TG2 looks really great. There is an incredible amount of range! More than you see in the typical HDR real-world photograph (light probe) I think. - Oshyan

Ah, ok. I thought you were doing all tests "clean". Otherwise, while they may be "practical" and "real world", they are unfortunately not reproducible, and thus not comparable to previous results. Simulating "real world conditions" for non-dedicated use situations is a whole art in itself. - Oshyan

Interesting! So the efficiency was actually reduced. Any theories as to why that is? - Oshyan

Ah, I see where you're coming from now. Well, from the perspective of practical use the overhead is undeniably minimal (not annoying, in other words). But from a benchmarking perspective, with such small sample times, you'd need to at least attempt to measure the overhead and subtract it (if it were significant enough to do so) in order to get a more accurate benchmark. One from which the results might safely be used to extrapolate to other hardware. Personally I would really appreciate seeing a slightly longer test for that reason - as I said, 30 seconds to 1 minute per frame. It need not even be as many frames. I think as long as each machine has a chance to render 5 frames, it's probably a good test. So that's 50 frames, or less than an hour of rendering. Up to you, but that's my humble request. Thanks for listening, and for sharing your results with us. :) - Oshyan

louget I'm not trying to knock what you've done in any way, I think you're providing some great info and I'm certainly appreciative. I'm only trying to offer advice from my own experience that might be helpful in ensuring accurate results. I have some personal experience in benchmarking and it's always been a subject of interest to me so I've done a good deal of research on it. One of the major consistent issues is minimizing non-related factors in your benchmark. For example if you're testing a game and want to find out what the maximum CPU bound framerate is, you want to ensure that the graphics card will not be a bottleneck, so you first use the fastest graphics card you have available, and 2nd you run the benchmark at extremely low resolution, since higher graphics resolutions depend almost entirely on the video card. The CPU will be stressed fully this way. The same principles apply to your situation of course. I'm sure I am not telling you anything you don't know, but perhaps this will explain to others what I am talking about. In any case it's all well and good to say that the overhead has no noticeable effect, but the real question is have you measured it? If so, then I'm sure you're correct and your results may reasonably used to extrapolate for other potential situations. But if not, and you are simply making a judgment call based on your experience, I'm sorry but I think that calls the results into some amount of question. The overhead is an unknown quantity - low, according to your experience, which I'm certainly willing to accept, but not necessarily immeasurably low, and when you're dealing with such short render times, as I said the influence of even a small overhead could be significant. Of course it may not be your intention that others extrapolate from your data to other potential situations, but people are likely to do so regardless. It is no duty of yours, but would certainly be appreciated - if you're going to publicize your results - if you would practice due diligence in ensuring their accuracy. It would be of benefit to all, including yourself. All that being said it's likely that if you retested with a longer rendering scene, the results would be similar and I might look a fool. But the principle of what I'm saying holds true. You simply can't safely make any assumptions when benchmarking, otherwise your results are largely useless. Last but not least I'd like to reiterate: please don't take offense to any of this. I am not saying I know better than you. I am largely regurgitating what I have learned in my own years of personal benchmark experience and especially learning from others who know more and have greater experience than I. Take that as you will, but above all please don't be upset by it. Life's too short. ;) - Oshyan

That last image looks best. The rest are pretty flat, although I know they can be made to look better. What's really lacking in all of these is the true sense of "volume". Not surprising considering they're not volumetric. Is there a way to somehow use these as density maps for one of the volumetric materials or something? Or maybe there's some other workaround. This is definitely promising though. - Oshyan

There is always overhead. You may be right that it would have a minimal impact, but with render times that low I have my doubts. Only one way to find out of course... ;) - Oshyan