I start with the same file and exactly same settings in the file, and I try to render it on a PC and then on a Mac.
I'm quite happy with the render results, but when I compare them, I noticed some differences. See below. For example, the black shadow near the bottom center have different shapes. What could be the possible cause? Do the Terragen preferences (Edit>Preferences...) make any difference?
Thanks :)
Btw, I've converted the bmp files to jpg to get under the 512KB attachment size limit. The original bmp and the jpg attached here look the same.
There are actually somewhat significant differences in the terrain shapes as well. This may be down to the differences in random number generators between platforms, but I think at least it should be better than this (from my own past experiments). What is your detail level?
- Oshyan
Detail level: 0.575
Anti-aliasing: 3
Ray trace objects: Enabled
GI:
Relative detail: 2
Sample quality: 2
Blur radius: 6
So... is there any way to solve this problem?
Hmm...0.575 is a bit lowish, though not that bad, but to say that's the cause...I don't know?
Do you have time to render them both at, say for example, 0.75 detail?
It's an apple product, what do you expect? It just isn't allowed to look the same as on other hardware, because then it wouldn't be magical. ;D
Quote from: Rimmon on May 18, 2010, 11:15:26 AM
It's an apple product, what do you expect? It just isn't allowed to look the same as on other hardware, because then it wouldn't be magical. ;D
;D this reply made me laugh, thank you ;)
Yes, and there's also differences in the clouds (most obvious to me is about 100 pixels from the left center, on the pc there's a small sphere shape cloud that's barely visible on the mac version.) **EDIT** I was backwards on this. It is barely visible on the pc version. :-[
I would guess there's small differences between the compilers -- maybe math (random number gen. as Oshyan suggested, may be the best guess) or graphics libraries. The shadows may be correct and just look different because of variations in the terrain.
So that means I can't get PC and Mac to render the same thing exactly, right?
I was trying to make an animation using both computers to cut the rendering time by half, but seeing that both computers render the same scene slightly differently makes me lose hope...
And here are two other renders, the settings haven't been changed except for detail, which was raised to 0.75.
Quote from: cr1 on May 18, 2010, 05:03:15 PMI was trying to make an animation using both computers to cut the rendering time by half, but seeing that both computers render the same scene slightly differently makes me lose hope...
Depending on different aspects of the animation you might be able to render the first half on PC and the second on Mac with a certain overlap on both ends to be able to blend them together in the middle.
Hi,
Unfortunately there will always be differences between renders from the Mac and Windows versions. The differences mainly come about due to the low level differences between how numbers are handled by the respective operating systems and CPUs. It simply isn't feasible for us to replace OS maths routines etc. with our own versions to ensure matching render appearance across platforms.
Regards,
Jo
Paris (U.E.), le 20/05/2010
Quote from: jo on May 19, 2010, 12:07:30 AM
Hi,
Unfortunately there will always be differences between renders from the Mac and Windows versions. The differences mainly come about due to the low level differences between how numbers are handled by the respective operating systems and CPUs. It simply isn't feasible for us to replace OS maths routines etc. with our own versions to ensure matching render appearance across platforms.
Regards,
Jo
[rant]
Back in a previous life... while doing my math thesis which did involve computer graphics and other computations (mostly scientific computation type), we (the team I was a part of) had recognized (as quite a great deal of other people have) that floating point operations are the bane of reproducibility and portability. We had devised a nice theory (which turned out to be a formalization of *fixed* point computation, with a few twists). We had devised tools, including *fast* trigonometrics, we had a hell of a good time... and we faded into common insignificance! Such is life, I guess...
[/rant]
I do not know for a fact that this is the root of the problem described here, but I have a strong suspicion it is.
Hubert Holin
Uh.. Shouldn't portable libraries like those from boost avoid exactly this problem?
They are quite close, I'd throw it towards floating point oddities. What type of machine hardware you using for the pc vs the mac etc? My guess also is that if you had a mac with windows dual booted you'd most likely get something identical (as you thought).
Terragen uses a lot of huge and super small numbers in calculations, called floating point numbers. These things are a nice way to get those larger/smaller numbers, but it is impossible to get them completely accurate, and depending on hardware these can actually change. Thats due to how they are represented in binary. For example a number such as .001 might actually be stored as .0009989471891999101, or as something like .00100000000001002030000001000. These small differences are what might be showing up in your renders.
This also why banks/investment firms/payroll companies/ etc hate upgrading hardware/software once they have something that works and they can know what will happen. If they upgrade something odd might happen to $0.000000000001 every transaction, which slowly builds up. They want predictability in what will happen.
I remember our group doing a rehost on a simulator the was written in Fortran. Talk about problems -- NANs (not a number) and various precision errors. This was a RT system with simulated bomb fall lines, missile trajectories, etc. A headache I wouldn't ever want to repeat. Twelve hour days, seven days a week for a couple months. :P
Actually, I think knowing the specs of the Mac and PC in question would be interesting and potentially useful. Are they both Intel-based?
- Oshyan
Hi,
Quote from: nikita on May 19, 2010, 07:06:00 PM
Uh.. Shouldn't portable libraries like those from boost avoid exactly this problem?
Not that I'm aware of. boost does provide a number of mathematical tools but they are mostly higher level than the stuff we're talking about.
We do actually use boost for a number of things, BTW.
Regards,
Jo
Hi,
I dual boot a couple of my Macs (quad boot one of them, OS X, Vista, Win 7 and Ubuntu ). I will try a render on Mac and Windows but even on the same machine I would expect there to still be differences. I don't think Windows and OS X share the exact same "numeric environment", if you see what I mean. Even above the processor level the OS still has influence over the way numeric computation is done.
Regards,
Jo
One of the computers runs on Windows Vista Home Premium (32-bit) with an Intel Core 2 Quad CPU Q8200 @ 2.33 GHz and 4 GB RAM.
The other one runs on Mac OS X 10.5.8 with a 2.4 GHz Intel Core Duo processor and 1 GB RAM.
So yes, both are using Intel processors.
Anyways, I think the only way to use the computers efficiently is to carefully plan my animations so that I can render them on both computers and then blend them together without degrading the final visual experience.
Quote from: Rimmon on May 18, 2010, 05:26:18 PM
Depending on different aspects of the animation you might be able to render the first half on PC and the second on Mac with a certain overlap on both ends to be able to blend them together in the middle.
Paris (U.E.), le 22/05/2010
Quote from: nikita on May 19, 2010, 07:06:00 PM
Uh.. Shouldn't portable libraries like those from boost avoid exactly this problem?
Bonjour
As Jo pointed out, Boost does not aim to do that, at present. Were there to be sufficient demand, then we (most likely: I) could put forward a library. However, demand has not materialized in the past so it is unlikely to be there in the future, at least the rather near future. Furthermore, we had only developed what we felt we needed (though of course I could develop the theory forward). As a technical aside, the implementation I did way back then was in C, whereas I have since moved on to use mostly C++ (and python), and I remember that there was some ugliness in the interface due to some limitations in the template mechanism (which may have been removed in the forthcoming 0x standard, no make that the 1x standard ;-) ). Last but unfortunately not least, as things stand today, between my day work and helping my kids do their homework, it's a wonder I can sleep even a few hours a day, so it would not be ready any time soon... But of course I would love to do so!
Hubert Holin (ranting again...)