Hi,
There are problems with large bitmaps. Some of you will already have noticed that rendering large images eg. for posters is impossible. TG can't allocate enough ram.
The same thing is happening (or seems to be happening) with large textures - i tried to load a 21600*100800 texture for my planet (a blue marble image) and TG is "Unablo to load" it.
nikita
If you don't mind me asking, what res are you rendering too, and how big will the planet be in frame? Unless you are going to be zoomed in really close, that size image is overkill. Say you are rendering to a 2k frame, and you can see the whole planet, using your image map we would see 50k pixels (half the planet, along the long side) squeezed into 2k. Essentially in that example you have roughly 25 times the detail you actually need, and would serve you better to resize the image map.
Like I said, I have no idea how close you want to be to this planet and how big the render will be, so forgive me if I am stating the obvious and poking my nose where it probably should not go ;)
I've been playing around with using image files for planets recently and, like njen, I would say thats a little overkill but We don't know the size of your frame so we can't exactly talk. For doing Orbital rendrs TGTP does not need such a large size becuase the quality is already blured by the atmosphere ( asuming you have one).
Regards,
Will
At the moment I'm talking about this one: http://nikita.tac-design.net/galerie/tg2/01-winterevening.jpg with a 5400*2700 overlay.
The coastline of europe isn't very sharp because europe is quite far north where data are stretched to fit the projection on a rectangular image which produces additional blur.
As I said - already at 1024*xyz it's starting to get a bit blurred, If I render a version for large resolution screens like 160*xyz it won't be sharp anymore. And now think of poster size.
Yes I cans ee what you mean hmm, neat shot by the way. Ill play around and see if I can't find a solution for you.
Regards,
Will
I don't think there's a workaround. TG will have to use some intelligent technique to allocate memory, maybe using an own pagefile like photoshop has.
At least rendering at poster size has to work :)
Nikita, how did you applied the Earth-map to the planet? I'm trying to do it through the image map shader or the defaut shader but I get strange effects (I have tried also all types of projection). Could you send your tgd file - the one you used to render your picture http://nikita.tac-design.net/galerie/tg2/01-winterevening.jpg?
You need the image map shader:
(http://nikita.tac-design.net/galerie/tg2/planettexture.gif)
I guess the trick ist, to specify the center of the sphere properly which is at (0,radius of planet,0) if you use the default planet.
Nikita, thank you for your hint. Now, everything is okey. Thanks.
Im writing a tururail on how to this stuff now so that should help people out a bit I hope.
Regards,
Will
I'm also having trouble rendering large images - a very consistent problem with any image over about 2400 x 1800. These are single image renders not animation. Using Full Render they run to approximately 2/3s complete then crash the TG2 app. I've run many renderings with .9 at 8500 x 4800 and higher, they take a bit of time but mostly never crashed the app and the results are very cool. Any ideas on getting by this limit would be most appreciated... TG2 is amazing, btw... Thanks
so I have been working on rendering an image tha is 30x40in @ 300 dpi(12,000x9,000 pixels) on a Mac Pro. I at 4 days of rendering and still only 25% of the way done. what should I do? TG2 is using all of the ram in the Mac Pro. the Mac Pro has 2GB of ram not a lot I know. the software is using 1.8GB of ram and 2.9 GB of Virtual Memory. 30x40in image will make a file that is 309.0 MB so why is it going to take 16 days to render?
Here is Oshyan's response to our thread on print quality/render times.....
http://forums.planetside.co.uk/index.php?topic=609.0 (http://forums.planetside.co.uk/index.php?topic=609.0)
12,000X9000...that's a huge image...my condolences....
If my calculations are correct and the reported size of the image map is right, that's a a 6.5GB image when uncompressed. :o Frankly I'm not surprised you're having problems in that case. Even if you had 8GB of RAM TG2 isn't yet capable of taking advantage of it since it's not 64 bit.
TG2 definitely needs better handling of image maps, including functionality to only load the part of an image that is being used in the actual render. Still I think it is a lot to ask to use an image map of that size. Some way to support mip mapping (multiple resolution versions of an image for different distances) might help. I'm quite sure we'll be improving handling of large textures in general, but I don't know the details of how exactly that will be dealt with.
As for rendering at larger sizes, this is definitely an area that has not yet received a great deal of development attention. Rendering at print sizes is not something I would recommend in the Technology Preview both because of the unoptimized state of the application and because of certain known memory-related issues with rendering at larger sizes. It's certainly possible to get it to work, but you are likely to experience frustration in the process, including crashes, lost renders, etc.
Keep in mind you're dealing with a Technology Preview here. I know it seems odd sometimes that many things work so well and yet others can be completely broken. It can lull you into a false sense of the application's maturity and you expect it to do things that perhaps are unreasonable. This is simply the nature of the development process. Many things will improve and much more will be possible by the time the final release is made later this year.
- Oshyan
6.5...wow
@Oshyan
Yes that's huge and I don't ask for support that soon. But there seems to be a general problem with allocating memory in TG2. Ok, 21600*100800
is almost insane, but rendering at poster size is a common problem.
The fact that rep is able to render at such large sizes on his mac suggests that it's the usual XP problem of windows being unable to allocate more than 2GB for a single application. If that's true, the 3GB switch or Vista might solve the problem.
QuoteMany things will improve and much more will be possible by the time the final release is made later this year.
:)
6.5 GB that is what I was thinking. With the computers on the market I do under stand why the software is not 64bit. Was this software meet to be released as Bata for testing not as a Preview? Can I get around the rendering problems with a multithread OS like Mac OS X server 10.4?
More effective memory management and CPU load handling optimization I am sure is on the list of things to do before release of the first commercial release version of TG2. The old Terragen had a memory Usage limit option in the "Advanced Tab" of the Render Settings where you could specify in Megabytes the maximum memory size of the render buffers; I really hope this will be returning to the finial release version.
From an "End User Frustration [EUF]" issue stand point is to do with some applications not releasing memory after they have finished with it the same can be true with applications not releasing CPU cycles after they have completed there use of them, the other area of concern would be memory leaks.
I am sure that TG2 is being tested for these problem areas but I raised them any way.
Oshyan you mentioned Mip-mapping, I was thinking about this the other day while reading another post which I believe was to do with a problem with instances in populations, where you have a high population density practically near the horizon where problems can arise with the perspective of these instances would mip-mapping if implemented be extended to populations as well as the prescribed case of image maps?
Regards to you.
Cyber-Angel
I believe population detail is already reduced with distance, but I think there is more room for optimization in this area. Level of detail functions, whether automatic or assisted, will probably be improved and expanded in the future to increase efficiency and lower resource use.
- Oshyan