Better Galaxy-map stars

Development of artwork, requests, suggestions, samples, or if you have artwork to offer. Primarily for the artists.
Message
Author
User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

#46 Post by Geoff the Medio »

eleazar wrote:Allowing a 256x256 graphic for the black holes is a more likely solution than adding a Halo. Currently it's squashed to 128x128
The blackholeN.png images I have now are 64x64... and there were none in the newest file.

User avatar
eleazar
Design & Graphics Lead Emeritus
Posts: 3858
Joined: Sat Sep 23, 2006 7:09 pm
Location: USA — midwest

#47 Post by eleazar »

Geoff the Medio wrote:
eleazar wrote:Allowing a 256x256 graphic for the black holes is a more likely solution than adding a Halo. Currently it's squashed to 128x128
The blackholeN.png images I have now are 64x64... and there were none in the newest file.
oops, i updated the black suns at this post.
these images are 128x128. I don't neccesarily want to make them bigger, that's just an option i considered, that the engine wouldn't allow.

I should mention that half-sizing the stars shouldn't be neccesary with the recently provided graphics. Reds and Blues will be pretty big, but the average, yellow stars should be about equivalent of the old yellow example file when it was half-sized.

Good night...
Last edited by eleazar on Sat Oct 28, 2006 3:38 am, edited 1 time in total.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

#48 Post by Geoff the Medio »

eleazar wrote:oops, i updated the black suns at this post.
these images are 128x128.
Uhm... the ones in that post are 64x64.

Also, in case missed: mouseover indicator quickie request? yes / no? Thanks...

Edit: I'm not sure why, but half the stars have only halo. Edit again: I think I know why... the engine is looking for files named, eg. "yellowSOMETHING.png", so it's grabbing the "yellow_halo.png" and treating it like a disc image. We'll need to rename them "halo_yellowN.png"... I suspect. (trying it...)

Also, at certain zoom levels, the particular shape and transparency of the halos makes some stars look octagonal.
Image
Last edited by Geoff the Medio on Sat Oct 28, 2006 3:48 am, edited 1 time in total.

User avatar
eleazar
Design & Graphics Lead Emeritus
Posts: 3858
Joined: Sat Sep 23, 2006 7:09 pm
Location: USA — midwest

#49 Post by eleazar »

Geoff the Medio wrote:
eleazar wrote:oops, i updated the black suns at this post.
these images are 128x128.
Uhm... the ones in that post are 64x64.

Also, in case missed: mouseover indicator quickie request? yes / no? Thanks...
Quickie indicator in this post:

Hmm, the spikes are a little too prominant.
remember the original motivation of separating the halo and core was to allow different rates of zooming. I don't expect these to look good if the halo doesn't shrink faster than the core.


as for the black holes, my FTP client shows 128sized files, but my web browser shows 64sized. Probably the correct files will show up in a few minutes. If not i'll fix it tommorrow.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

#50 Post by Geoff the Medio »

Renaming the halo files fixed the lack of discs issue:
Image

tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

#51 Post by tzlaine »

Geoff the Medio wrote:Edit: I'm not sure why, but half the stars have only halo. Edit again: I think I know why... the engine is looking for files named, eg. "yellowSOMETHING.png", so it's grabbing the "yellow_halo.png" and treating it like a disc image. We'll need to rename them "halo_yellowN.png"... I suspect. (trying it...)
Right. I made a change recently so that files are searched for using filename prefixes, instead of a fixed number of numbered files. So now, default/art/stars/yellow* will be treated as candidates for yellow star graphics. This was designed to make it easier for artists to just drop in new graphics without changing the code.

Wolverine
Space Floater
Posts: 44
Joined: Wed Apr 13, 2005 6:07 pm
Location: Warsaw, Poland

#52 Post by Wolverine »

Don't get me wrong, but those new stars doesn't look very good. In fact I'd prefer the old ones... These are reminding me bad taste graphics from some rather cheap games really. I hope you're not going to pursue those images in the next release.
The emperor wants to control outer space. Yoda wants to control inner space. That's the fundamental difference between the good and the bad sides of the force... - Mof, Human Traffic ;)

User avatar
pd
Graphics Lead Emeritus
Posts: 1924
Joined: Mon Mar 08, 2004 6:17 pm
Location: 52°16'N 10°31'E

#53 Post by pd »

I second what Wolverine said - I don't like them either.

They could work for a more close-up view, though. May we we could try using both stars types. For far away views we are using the old ones, for close ups the disk-like stars. The blend should be as smooth as possible.

User avatar
eleazar
Design & Graphics Lead Emeritus
Posts: 3858
Joined: Sat Sep 23, 2006 7:09 pm
Location: USA — midwest

#54 Post by eleazar »

eleazar wrote:Here, is a set of stars that show roughly how size and brightness can correspond to real star types while still retaining the stars usability. It's a proof-of-concept, not a polished product.
(emphasis added)
pd wrote:They could work for a more close-up view, though. May we we could try using both stars types. For far away views we are using the old ones, for close ups the disk-like stars. The blend should be as smooth as possible.
eleazar wrote:Hmm, the spikes are a little too prominant.
remember the original motivation of separating the halo and core was to allow different rates of zooming. I don't expect these to look good if the halo doesn't shrink faster than the core.
The idea from the beginning of this topic is to have the halos very small while zoomed out. This hasn't been implemented yet.

User avatar
eleazar
Design & Graphics Lead Emeritus
Posts: 3858
Joined: Sat Sep 23, 2006 7:09 pm
Location: USA — midwest

#55 Post by eleazar »

I've updated the halos to have more glow and less spike.
This replaces the previous zip.

I can't highly refine the graphics without seeing them in-game myself. But i should be able to get them in better shape before the next release.

User avatar
eleazar
Design & Graphics Lead Emeritus
Posts: 3858
Joined: Sat Sep 23, 2006 7:09 pm
Location: USA — midwest

#56 Post by eleazar »

I got on a windows machine and downloaded RC5 (i had really hoped it wouldn't take this long to get a mac compiled version)
I brought in my separate star & halo graphics, intending to fine-tune them, but the scaling was way off.
The idea was that the halos at maximum zoom would have scaled twice as much as the star cores. However it seems that they increase three or four times as much, which gives way too much halo at high magnification.

this link once again updated with RC5 compatible names.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

#57 Post by Geoff the Medio »

eleazar wrote:The idea was that the halos at maximum zoom would have scaled twice as much as the star cores. However it seems that they increase three or four times as much, which gives way too much halo at high magnification.
There's a couple complications with that, and it's not clear what "scaled twice as much as" something means:

Depending on what you meant, there needs to be a reference point. For example, if the star cores and halos are both are size 1 at zoom level 1, then if I go to zoom level 8, linearly scaling the halos twice as fast as the core would produce star cores would be size 8 and halos size 16. But you've only given one end of the relationship: (max zoom core size, 2x halo scale factor). I need another point on the line to know how to scale things properly... Think rise over run from high school line slope finding. I've got one point, but need another to have two sets of coordinates to subtract to get the rise and the run.

Regardless of the above, what I'm currently doing is a sort of logarithmic scale. I start with the zoom factor for a given zoom level, which is the relative size of the halo to some arbitrary size in code, and which ranges between about 0.25 and 8. I take the base 10 logarithm of this, and add 1. For zoom level 8, the highest zoom, this produces a factor of about 1.9, which is used as the scaling factor of the halo relative to the star core. So, if the star core was 20 pixels across, the halo would be 38 pixels, which is just under twice as big by diameter. I found this logarithmic-type scaling gave a nice variation with zoom.

This is just the largest size of the halo though, relative to the star core. I figured this was what was meant by "scaled twice as much". However you could also mean that the relative scaling factor difference should vary by a factor of 2. By this, I mean that the halo is bigger than the core by a factor of "scaling factor - 1". ie. if the halo size scaling factor is 1.8, then the halo is a factor of 0.8 bigger than the core. You might have meant that halo's size should vary between some scaling factor difference at minimum, and some other factor that is twice as big at maximum. For example, at minimum zoom, the halo could be 1.4 times the size of the core, but at max zoom, it could be 1.8. Or 5.2 and 9.4, or 1.01 and 1.02.

Also, twice as big diameter means four times as big area, and twice as big area means square root of two times bigger diameter.

Also, what happens if we change the max zoom level? Does the halo size at every other zoom change, or can the halo grow bigger than whatever is meant by twice as big, allowing the other sizes to be unchanged?

Also, I'm scaling the core and halo images I'm given. If the core image or halo image doesn't fill the whole width of the image, then the relative scaling factors between a core and its halo might be off. The stars provided have various different disc sizes within (and always smaller than) a fixed size image. I'm not going to be able to tell what size the disc is in an arbitrary image, so a halo size ratio taking into account the typical actual disc size and halo size relative to their respective image sizes would be helpful...

Also, I'm running FO with the images you gave, and I'm not seeing the cores after I change from the default zoom level. It seems that, despite specifically attempting to do otherwise, I'm drawing the halos over the cores, and covering them up. This might be throwing off your estimates of halo size...

Edit: It seems I wasn't really running with the new images you provided, due to their naming scheme being slightly different from the SVN ones. I've removed all the conflicting SVN images, and now see, I think, more core when expected... /Edit

Anyway... maybe you should draw some very clear and numerous pictures at a variety of zoom levels to illustrate what you want...

User avatar
eleazar
Design & Graphics Lead Emeritus
Posts: 3858
Joined: Sat Sep 23, 2006 7:09 pm
Location: USA — midwest

#58 Post by eleazar »

Geoff the Medio wrote: ....

Anyway... maybe you should draw some very clear and numerous pictures at a variety of zoom levels to illustrate what you want...
I guess i wasn't as clear as i thought it was. I'll provide clearly labeled charts and so-forth.

Question as i prepare:
does zooming happen in chunky increments, or is that just the way my mousewheel works?

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

#59 Post by Geoff the Medio »

eleazar wrote:does zooming happen in chunky increments, or is that just the way my mousewheel works?
There is a fixed ZOOM_STEP_SIZE, and the zooming function is written such that it only ever multiplies or divides the zoom level by one increment of this value to change the zoom level (ignoring minor rounding quirks). This could be changed, however.

User avatar
eleazar
Design & Graphics Lead Emeritus
Posts: 3858
Joined: Sat Sep 23, 2006 7:09 pm
Location: USA — midwest

#60 Post by eleazar »

Geoff the Medio wrote:
eleazar wrote:does zooming happen in chunky increments, or is that just the way my mousewheel works?
There is a fixed ZOOM_STEP_SIZE, and the zooming function is written such that it only ever multiplies or divides the zoom level by one increment of this value to change the zoom level (ignoring minor rounding quirks). This could be changed, however.
I just wanted to verify that what i'm seeing is normal.

Also has the max size of Cores changed between RC4 and RC5, or is it dependent on screen size?

Post Reply