User talk:Valaggar/PlanetBox

From Ultronomicon
Jump to navigation Jump to search

To continue some of the discussion here rather than clutter up Svdb's page - If I can interject some thoughts on this, it might look better with the "type" box beneath the planetary data - also i don't think it's necessary to say what the satellite types are just how many of them there are. This field could be merged into the planetary data section. Also as to the map size, I'd recommend 242x75, the size of the eartmask.png, or 232x67, the size of the orview.19.png. I couldn't find any other set example of a map in the UQM content files though. That said, do you mind if I or others tweak this page a bit to experiment with the appearance? --Fyzixfighter 10:44, 1 May 2007 (CEST)

You can tweak it how you want.
As to satellite types - well, it makes a BIG difference to look at the sky and see a Water World moon, for example. And it doesn't clutter the PlanetBox at all. Just a few extra characters.
Planet type box moved below detailed data.
Speaking of merging the satellite data with data on the planet - well, you can see it better in the planet type box, as it's related to the "planet at a glance" information rather than detailed data.
I don't know what's up with eartmask.png, but if you zoom in to the topomaps here you can see that there are no macropixels (former pixels divided into multiple pixels). I guess this is because of the scaler, but it looks better at the current resolution. Valaggar 11:10, 1 May 2007 (CEST)
Hey Val, what were the graphic settings you were using when you took the topomap images? I'm trying to compare how these look at different settings. Just FYI, using the lowest resolution (equivalent to the original SC2) the images are 242x75 like the eartmask.png. --Fyzixfighter 06:44, 2 May 2007 (CEST)
1024x768. Windowed, if this matters. Valaggar 14:10, 2 May 2007 (CEST)
Thanks - Which scaler was it using? --Fyzixfighter 16:08, 2 May 2007 (CEST)
HQ. As a side note (17:05 CEST), I can re-take the screenshots, there's no need to do it yourself. Valaggar 16:53, 2 May 2007 (CEST)
While the advanced scalers tend to look less pixelated, there is a problem with trimming the grey border. With any of the scalers, the border and topomap bleed together for a few rows/columns of pixels. I'd be more in favor of using the unscaled topomaps, like we did for the alien artifacts (granted it was easier for those since the raw images existed and were easily accessible). And since its the rawest data, anyone can then go and easily apply the various algorithms to create a smoothed out image; unconvoluting a scaled image on the other hand is a pain - though I don't know how or if the same argument holds up for the 3d planet image. But since that's generated from the topomap (and the 3d image generation has changed significantly for UQM), I think a good compromise would be to use the HQ, high-res 3d image, and the none-scaled, low-res topomap. Oh and don't worry, I'm only tinkering around with a single topomap, checking out the various resolutions and scalers. And with that, I'm off to work. --Fyzixfighter 17:34, 2 May 2007 (CEST)
You've got the point here. Don't worry, I'll do the grunt work. My plan is to take the shots with no scaler and apply a 100% Low Pass with a radius of 2 pixels, and it looks much better than with any scaler, plus with no cut columns or rows. Valaggar 17:46, 2 May 2007 (CEST)
EDIT: BTW, the HQ scaler does not cut any columns or rows, it's just an illusion. Anyway, I feel that the low pass works better. I don't know if you agree, though. Uploaded Gamma Serpentis I with Low Pass from No Scaler for comparison: Expepix.jpg
and here is the HQ Gamma Serpentis I: GammaserpentisiMap.jpg
Hmm... maybe the HQ version is the best, now that I glance upon the image again. Valaggar 17:58, 2 May 2007 (CEST)
It's not that the HQ removes rows/columns - it's that the HQ blends the grey border with the topomap. Zoom into the interface region (preferably an area with some variety like a continent) and you'll see what I mean. Really, any of the in-game scalers will produce this since it's using the neighboring pixels to interpolate the extra pixels. I imagine you could take the cropped raw image without the grey border and then interpolate, but since which interpolative algorithm to use is so subjective I'd still rather just keep to the raw data, even though it does look more pixelated. --Fyzixfighter 19:22, 2 May 2007 (CEST)
I've already looked at various land forms, all 4 borders, and, frankly, there's NO pixel screwed by HQ that wasn't already screwed by the transition effect present in the non-scaler mode too. If you'd supplement your view with a screenshot on which to show the exact screwed areas, I might reconsider my PoV. Valaggar 20:06, 2 May 2007 (CEST)
Strange, since I see it just fine. Yes I know these aren't from the same planet, but they demonstrate the point (and sorry for the whitespace). Highest resolution with no scaling, zoomed in on the interface: Uranus none zoomed.PNG
And zoomed in on the interface for highest resolution and HQ scaling GserpHQzoomed.PNG Notice how in the none-scaled region, the interface is very clean, while in the HQ version the light grey strip blends blends with the top row of the topomap. This is what I was talking about and why I would still advocate using the raw, lowest-res, none scaled image. --Fyzixfighter 23:32, 2 May 2007 (CEST)
OK, now I see. But it's not that much. Not that much to motivate giving up the image's quality. Let's see what others say. Valaggar 14:47, 3 May 2007 (CEST)

Making the whole "1 satellite" text a link doesn't look like a good idea to me. It looks bad, plus what would you do if you have 2 satellites?

Anyway, it's good that you found the 242px value. It looks better now.

Finally - looking at the double topomap, it's easy to see that there is no visible difference. It would not be a bad idea to keep the not-scaled images too, I think each of them should have a link from the scaled images (i.e. in EtavulpeculaeiiMap.jpg's description there is a "Low resolution image" link). Valaggar 08:09, 5 May 2007 (CEST)