Texture rotation

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

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

Re: Texture rotation

#31 Post by pd »

To use a static image to give the galaxy shape / colour between stars, it's going to have be fixed in position and scaled relative to the stars, not free-moving and zoom-independent like the current background stars...
That's right and might be the biggest problem with this method, considering we want to avoid bluring when zooming in as much as possible and the resulting insane resolutions those images would then need to be. Anyway, I discard this idea and prefer the sprite method now.
I'm not sure which suggestion you're referring to here, but one of the ideas was to use the set of triangles on which starlanes are laid out to generate texturable triangles that fit the shape of the galaxy.
That's exactly what I was referring to.
These triangles would be fixed in position relative to the stars. This wouldn't add depth, but would let the shape of the sparse colouration (not discrete nebulae like we have now) fit the shape of the galaxy. The triangles could be classified by size, so that denser regions with smaller triangles could be differently textured, which would make this method more galaxy-shape independent.
How hard would it be to have those triangles moving depending on how the user pans the galaxy? It's just a collective movement along x or y after all, isn't it?
Additionally, putting stars or volume clouds in 3D space near the plane of galaxy stars could be done. These would be points for stars, or perhaps sprites, just like nebulae in the galaxy are now, but probably not sprites consisting of just stars. These would be drawn according to perspective, and would move around slightly faster or slower than the stars in the plane of the galaxy, to show parralax that actually makes sense physically and which would indicate that the galaxy has some 3D depth to it. This is distinct from the current background starfields that scroll at a rate completely independent of the zoom level and in now way related to the actual galaxy stars.
Sounds interesting and definitely worth exploring.
We could define sets of nebulae of similar colours. For any given game, only nebulae from one set would be used, giving the galaxy a (variety of) consistent "theme(s)".
Good idea.
The graphics brainstorming portion of this should probably get moved to the graphics forum...
I've started a thread about this. Further discussion about nebulae and background stars should be done there,since we are quite off-topic here. I've provided some mockups there as well.

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

Re: Texture rotation

#32 Post by eleazar »

Geoff the Medio wrote:
The Silent One wrote:Maybe we could increase the nebula size in relation to galaxy size instead of increasing the number of nebulae.
Read my post above about how they can't be any bigger without being ridiculously large.
[/quote]
Silent, that's a good idea.

Geoff the Medio wrote:Also, at their current size, they're about as big as they'd need to be if they were going to have some gameplay effect (like limiting cloaking or similar)... we wouldn't want this sort of effect covering fifty stars or more.
If they are given a gameplay effect, they would probably need to be redone from the ground up-- possibly procedurally generated. I don't see how that "maybe" is relevant to what we do now.

The purpose of Nebulae now, is to serve as "landmarks" in the galaxy, as well as make FO look cooler.

Geoff the Medio wrote:They're also currently much larger than nebulae in MOO3 or MOO1:
I don't see how that matters at all. :wink:
Geoff the Medio wrote:Regarding filling in space with *something* to give the galaxy more shape, from another pm:
I've already described (briefly) a way that would theoretically work. Why list a bunch of other ways which won't?

In regards to that, what would be the performance effects of adding 500 small (256x256 max), nebula-like blobs to a full size map?

And forget what i said about adding graphics only in the space enclosed by star-lanes... i think an equally good effect could be achieved by only placing the blobs at star coordinates.

The following example places a blob of blue at each star. The opacity increases closer to the center— this effect might need to be disabled for certain galaxy shapes. It works, but of course it might be too processor intensive.

EDIT: having connection problems and can't get the image attached.
Attachments
galaxy.jpg
galaxy.jpg (68.66 KiB) Viewed 1984 times

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

Re: Texture rotation

#33 Post by Geoff the Medio »

An actual programming post... woo!

In reply to this post...
tzlaine wrote:FWIW, we can probably beat this FPS figure by quite a lot by rewriting the starmap rendering code. We currenty don't batch anything, but we could batch everything. This would probably have been needed for large maps even without these new decorations.
I tried the following to "batch" the textures. Each texture has a set of object ids over which it is drawn, and the same texture is repeatedly rendered for each of its ids. This requires only one texture bind per nebula texture. This also uses gl rotation, translation and scaling (which may be of interest to Flatline), in the hopes that this would be a bit faster. I end up with 11 FPS for a 500 star galaxy, which may or may not be significantly better than the 5 reported earlier. Either way, not really enough of an improvement. Any suggestions for how else to improve?

Code: Select all

    const Universe& universe = GetUniverse();
    const float GAS_SIZE = ClientUI::SystemIconSize() * 16.0;
    const float HALF_GAS_SIZE = GAS_SIZE / 2.0;
    glColor(GG::Clr(255, 255, 255, 50));
    for (std::map<boost::shared_ptr<GG::Texture>, std::vector<int> >::iterator it = m_gaseous_substance.begin(); it != m_gaseous_substance.end(); ++it) {
        const boost::shared_ptr<GG::Texture>& texture = it->first;
        glBindTexture(GL_TEXTURE_2D, texture->OpenGLId());
        glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);

        std::vector<int>& sys_ids = it->second;
        for (std::vector<int>::const_iterator sys_it = sys_ids.begin(); sys_it != sys_ids.end(); ++sys_it) {
            const UniverseObject* obj = universe.Object(*sys_it);
            if (!obj)
                continue;
            glLoadIdentity();
            glTranslatef(static_cast<float>(obj->X() * m_zoom_factor + ClientUpperLeft().x), static_cast<float>(obj->Y() * m_zoom_factor + ClientUpperLeft().y), 0.0f);
            glRotatef(*sys_it * 27.0f, 0.0f, 0.0f, 1.0f);
            glScalef(m_zoom_factor, m_zoom_factor, 1.0f);
            glBegin(GL_TRIANGLE_STRIP);
                glTexCoord2f(0.0, 0.0); glVertex2i(-HALF_GAS_SIZE, -HALF_GAS_SIZE);
                glTexCoord2f(1.0, 0.0); glVertex2i( HALF_GAS_SIZE, -HALF_GAS_SIZE);
                glTexCoord2f(0.0, 1.0); glVertex2i(-HALF_GAS_SIZE,  HALF_GAS_SIZE);
                glTexCoord2f(1.0, 1.0); glVertex2i( HALF_GAS_SIZE,  HALF_GAS_SIZE);
            glEnd();
        }
    }
    glLoadIdentity();

m_k
Space Floater
Posts: 33
Joined: Wed Mar 12, 2008 10:54 am
Location: Aachen, Germany

Re: Texture rotation

#34 Post by m_k »

Maybe you could try to compile them into a display list once at universe generation/loading for at least the higher zoom factors. I never tried them personally, but as far as i know they should at least reduce some of the overhead like getting the stars positions everytime and some of the internal graphical stuff involved.

Another even more drastic idea would be to glue all the textures into one big galaxy texture (or several smaller) after universe generation, by rendering them once and then saving the resulting picture as a new texture, or something like this. I just know basic OpenGl, so it's hard to tell if this is even possible without using some other tools.

All theses ideas of course have the disadvantage that they are somewhat static and have to be generated anew if we allow the changing of galaxy objects.

User avatar
Flatline
Space Squid
Posts: 64
Joined: Tue Jan 29, 2008 2:06 pm
Location: Oxford (UK)

Re: Texture rotation

#35 Post by Flatline »

m_k wrote:Another even more drastic idea would be to glue all the textures into one big galaxy texture (or several smaller) after universe generation, by rendering them once and then saving the resulting picture as a new texture, or something like this. I just know basic OpenGl, so it's hard to tell if this is even possible without using some other tools.
I think that's the only solution, but I have an even-more-basic-almost-null knowledge of how opengl works (I lost half an hour trying to understand why the rotation code didn't work: opengl doesn't use the engineering-friendly radians, but the dull degrees :P)...

I found on the net this example (attached to post): I think it exactly does what we need. But as I said with my small knowledge of opengl I didn't completely understand it. Anybody can comment the DisplayFunc()?

(I'd like to try to figure out how it works right now... but I'm at work and I need to start doing something productive :D)

All theses ideas of course have the disadvantage that they are somewhat static and have to be generated anew if we allow the changing of galaxy objects.
Yes of course, but it's a one-time regeneration instead of an every-single-frame one :)
(and, moreover, what tech could change the shape of a background nebula? :D)
Attachments
RenderToTexture.zip
(2.92 KiB) Downloaded 118 times
The only difference between a suicide and a martyrdom is press coverage.
- Chuck Palahniuk (Survivor)

Ubuntu 7.10/Windows Vista/Windows XP (VMWare)/Windows NT 4 (VMWare) on Intel Centrino Duo [email protected] with NVidia GeForce GO 7600

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

Re: Texture rotation

#36 Post by Geoff the Medio »

We wouldn't just make one texture with all the galaxy nebulae and gassy bits on it at the start of the game (or rather, turn), as we'd need to make this full resolution for the maximum zoom possible, which would be ridiculously large. I suspect that instead, each time the view of the galaxy changes, due to dragging or zooming in or out, we'd regenerate the relevant texture, and subsequent rendering updates would use this texture to cover the screen.

But, I also suspect that there is more than can be done to improve the rendering speed when redrawing each gassy texture each frame, as my attempts are rather uninformed.

User avatar
loonycyborg
Compilation Expert
Posts: 219
Joined: Thu Jul 06, 2006 10:30 pm
Location: Russia/Moscow

Re: Texture rotation

#37 Post by loonycyborg »

Flatline wrote:But as I said with my small knowledge of opengl I didn't completely understand it. Anybody can comment the DisplayFunc()?
It's already well commented. What did you not understand about it?
In Soviet Russia, forum posts YOU!!

User avatar
Flatline
Space Squid
Posts: 64
Joined: Tue Jan 29, 2008 2:06 pm
Location: Oxford (UK)

Re: Texture rotation

#38 Post by Flatline »

loonycyborg wrote:
Flatline wrote:But as I said with my small knowledge of opengl I didn't completely understand it. Anybody can comment the DisplayFunc()?
It's already well commented. What did you not understand about it?
Well, mostly the buffer part... but probably more than a comment on THIS code I need a "how to start with opengl"/"basic opengl concept" tutorial :D

Any link on good material from the opengl experts? :D
The only difference between a suicide and a martyrdom is press coverage.
- Chuck Palahniuk (Survivor)

Ubuntu 7.10/Windows Vista/Windows XP (VMWare)/Windows NT 4 (VMWare) on Intel Centrino Duo [email protected] with NVidia GeForce GO 7600

User avatar
loonycyborg
Compilation Expert
Posts: 219
Joined: Thu Jul 06, 2006 10:30 pm
Location: Russia/Moscow

Re: Texture rotation

#39 Post by loonycyborg »

Flatline wrote: Any link on good material from the opengl experts? :D
OpenGL Red Book is considered to be good material by OpenGL experts. Also, there are OpenGL man pages(E.g. try "man glNewList").
In Soviet Russia, forum posts YOU!!

User avatar
Flatline
Space Squid
Posts: 64
Joined: Tue Jan 29, 2008 2:06 pm
Location: Oxford (UK)

Re: Texture rotation

#40 Post by Flatline »

loonycyborg wrote:
Flatline wrote: Any link on good material from the opengl experts? :D
OpenGL Red Book is considered to be good material by OpenGL experts. Also, there are OpenGL man pages(E.g. try "man glNewList").
Thanks for the input, I'll give it a try :)

Geoff the Medio wrote:We wouldn't just make one texture with all the galaxy nebulae and gassy bits on it at the start of the game (or rather, turn), as we'd need to make this full resolution for the maximum zoom possible, which would be ridiculously large. I suspect that instead, each time the view of the galaxy changes, due to dragging or zooming in or out, we'd regenerate the relevant texture, and subsequent rendering updates would use this texture to cover the screen.

But, I also suspect that there is more than can be done to improve the rendering speed when redrawing each gassy texture each frame, as my attempts are rather uninformed.
So I think that mostly two strategies should be used:
* Create one single texture from what is displayed on screen as BG (i.e. BG nebula & starfield) and use it to draw BG. This function should be called at each drag and zoom;
* Reduce the number of TRIANGLE_STRIP used. Perhaps we could draw only one texture which spans multiple near stars (1 texture for 2/3 stars, centering and orientating it with the stars).
The only difference between a suicide and a martyrdom is press coverage.
- Chuck Palahniuk (Survivor)

Ubuntu 7.10/Windows Vista/Windows XP (VMWare)/Windows NT 4 (VMWare) on Intel Centrino Duo [email protected] with NVidia GeForce GO 7600

m_k
Space Floater
Posts: 33
Joined: Wed Mar 12, 2008 10:54 am
Location: Aachen, Germany

Re: Texture rotation

#41 Post by m_k »

Geoff the Medio wrote:We wouldn't just make one texture with all the galaxy nebulae and gassy bits on it at the start of the game (or rather, turn), as we'd need to make this full resolution for the maximum zoom possible, which would be ridiculously large. I suspect that instead, each time the view of the galaxy changes, due to dragging or zooming in or out, we'd regenerate the relevant texture, and subsequent rendering updates would use this texture to cover the screen.
I was under the assumption that the current approach of rendering all the individual textures should be sufficient for zoomed in view, because there are just several dozens of our background nebulas involved, so a sufficient size for the big texture would be somewhere in the order of magnitude of the screen resolution. A possible problem with generating the relevant texture while dragging could be that we probably will produce a noticeable lag in moving everytime a new texture is needed, or if we "outsource" it into another thread it would be possible to see portions of the galaxy before the background is generated. (Compare it to google maps where you sometimes have to wait some split seconds before the satelite images are loaded.)

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

Re: Texture rotation

#42 Post by Geoff the Medio »

m_k wrote:A possible problem with generating the relevant texture while dragging could be that we probably will produce a noticeable lag in moving everytime a new texture is needed...
I consider dropping to 5 or 10 FPS for a few frames when zooming or dragging much preferable to constant 5 or 10 FPS regardless of whether the view is being altered. We generally don't have a lot of continuous smooth scrolling happening, so it's not completely unreasnable to talk about the slowdown only happening for a few frames.

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

Re: Texture rotation

#43 Post by eleazar »

geoff wrote:Any suggestions for how else to improve?
i've changed the textures to 128x128.

I expect the quality will still be sufficient, especially if each texture receives a random rotation.

If that doesn't work we could look at skipping the texture for approximately half the stars in closely packed areas. We could get a similar effect if we increased the opacity of each sprite, but didn't assign sprites to so many overlapping layers. It's possible such a method would actually look better... at least in some situations.

But if you can solve the issue with some arcane coding, that's cool too.

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

Re: Texture rotation

#44 Post by pd »

Geoff the Medio wrote:
m_k wrote:A possible problem with generating the relevant texture while dragging could be that we probably will produce a noticeable lag in moving everytime a new texture is needed...
I consider dropping to 5 or 10 FPS for a few frames when zooming or dragging much preferable to constant 5 or 10 FPS regardless of whether the view is being altered. We generally don't have a lot of continuous smooth scrolling happening, so it's not completely unreasnable to talk about the slowdown only happening for a few frames.
It might be interesting to see how this behaves on other systems. So for a possible next release candidate this feature should be included, but probably deactivated by default.

User avatar
Flatline
Space Squid
Posts: 64
Joined: Tue Jan 29, 2008 2:06 pm
Location: Oxford (UK)

Re: Texture rotation

#45 Post by Flatline »

eleazar wrote:
geoff wrote:Any suggestions for how else to improve?
i've changed the textures to 128x128.
Tried it. On my PC I get 30FPS at any zoom level, and the quality is perfect.
There's still a lot of room for improvements (my CPU is almost at 100% all the time), but it's a good step in the right direction :))
(I'm on a dual monitor setup, so I'm not 100% sure that my NVidia uses 3D acceleration... I'll try this at home and see if the performances get better).
The only difference between a suicide and a martyrdom is press coverage.
- Chuck Palahniuk (Survivor)

Ubuntu 7.10/Windows Vista/Windows XP (VMWare)/Windows NT 4 (VMWare) on Intel Centrino Duo [email protected] with NVidia GeForce GO 7600

Post Reply