Donation

Help us to pay our server!
(: Consider a donation :)



Social Media

  • Facebook
  • Google+

Latest Posts

Topic: Attempting world-specific new roads

Forums » Widelands Development » Graphic Development » Attempting world-specific new roads



Astuur
Avatar
Joined: 2009-02-28, 12:08
Posts: 733
Ranking
One Elder of Players
Location: Frankfurt / Germany
Posted at: 2011-10-09, 10:25

I was immediately thinking about your buildings and shared your concerns initially -
but on second thought, I hope it will not matter.

My idea is, that anything moving along the roads does not really care about the road graphics.

  • I assume that, carriers will check whether a road to coordinates x|y does exist, and if so simply are given the permission to use it.
  • I go on assuming that they will then check the altitude coordinates to determine the time the animation should be played to reach these coordinates (road steepness).
    Knowing these things, I expect the carrier animation will steer a direct line to this spot. So they will use the "center line" of the road, and since carriers, beasts of burdon, wares etc. are usualy wider than 5 pixels anyhow, they, and not the road texture will conflict with any building. So there is no change in this respect.

Could anyone knowledgable please verify this from code, and correct my thoughts if necessary!

The extra 2 pixels that I am proposing here, are not meant to visually broaden the road. (in any case not the "normal" ones)
Instead, I had in mind to have them semitransparent and so do some modest blending with the underlying terrain.
Alternatively, or may be in addition, I am thinking about using these to let the roads vary a bit in width (at flags and where carriers stand) in order to overcome the "straight cut" impression a bit.
For high-traffic roads I am playing with the idea of a lining and paving, and maybe an increased width. But that will only be possible if those roads can be broadend.


Being no programmer, I apologize for all my suggestions that imply undue workload and for other misjudgements due to lack of expertise or relevant skills.
I am on Win32, have no means to compile, and rely on prefabricated distributions (Thanks to Tino).

Top Quote
SirVer
Joined: 2009-02-19, 17:18
Posts: 1324
Ranking
One Elder of Players
Location: Germany - Munich
Posted at: 2011-10-09, 13:26

I assume that, carriers will check whether a road to coordinates x|y does exist, and if so simply are given the permission to use it.

Correct.

I go on assuming that they will then check the altitude coordinates to determine the time the animation should be played to reach these coordinates (road steepness). Knowing these things, I expect the carrier animation will steer a direct line to this spot.

Correct.

The extra 2 pixels that I am proposing here, are not meant to visually broaden the road. (in any case not the "normal" ones)
Instead, I had in mind to have them semitransparent and so do some modest blending with the underlying terrain.
Alternatively, or may be in addition, I am thinking about using these to let the roads vary a bit in width (at flags and where carriers stand) in order to overcome the "straight cut" impression a bit.
For high-traffic roads I am playing with the idea of a lining and paving, and maybe an increased width. But that will only be possible if those roads can be broadend.

I am very much intrigued by this work. Making the roads wider should not be a big problem, I am unsure about transparency though, especially in the software renderer.

Cheers, !SirVer


Top Quote
Astuur
Avatar
Joined: 2009-02-28, 12:08
Posts: 733
Ranking
One Elder of Players
Location: Frankfurt / Germany
Posted at: 2011-10-09, 13:57

Thanks a lot, SirVer
I'm always thankful to be so reliably supported when we get stuck here with code-related questions.

Now -- who can give us his preliminary assessment, whether transparency with software rendering will be feasable?

Or is it to be replaced anyhow with OpenGL on the long run, and we should not care much about it?
I have learned that some still prefer it for its softer borders.

My problem is that WL itsself is the only testing environment for my graphic changes, and as long as none of the changes mentioned above are implemented, I can not verify any results.


Being no programmer, I apologize for all my suggestions that imply undue workload and for other misjudgements due to lack of expertise or relevant skills.
I am on Win32, have no means to compile, and rely on prefabricated distributions (Thanks to Tino).

Top Quote
SirVer
Joined: 2009-02-19, 17:18
Posts: 1324
Ranking
One Elder of Players
Location: Germany - Munich
Posted at: 2011-10-10, 12:36

Heyho,

We decided to keep the software renderer around for those boxes who do not have OpenGL. As now every new computer has OpenGL in some form or another, we might rethink this. I personally hate to have to branches of code that need maintenance and development, I would rather switch sooner than later. But of course, the discriminating factor are our users.

About the software rendering: every coder can verify if transparencies are a possibility in software rendering. They just need to dig into the code. The best one to ask would be Timowi or ixprefect, afaik they have worked on the code the latest.


Top Quote
Astuur
Avatar
Joined: 2009-02-28, 12:08
Posts: 733
Ranking
One Elder of Players
Location: Frankfurt / Germany
Posted at: 2011-10-11, 20:55

Ixprefect has kindly already reacted to my request for his assessment.

Without further investigation so far, he thinks that a border transparency might be possible by doing something with "the offset inside the inner loop"
I've no idea what that means, but I trust him in any case face-smile.png

"Real alpha transparency" could be too expensive though, he continues (workload for the CPU or the programmer?)
He'll come back when he has looked deeper inside the code.
So ... keep you fingers crossed, everyone...


Being no programmer, I apologize for all my suggestions that imply undue workload and for other misjudgements due to lack of expertise or relevant skills.
I am on Win32, have no means to compile, and rely on prefabricated distributions (Thanks to Tino).

Top Quote
Astuur
Avatar
Joined: 2009-02-28, 12:08
Posts: 733
Ranking
One Elder of Players
Location: Frankfurt / Germany
Posted at: 2011-11-10, 09:49

The "better roads" project is currently on hold, until the programmers have decided about a possible alpha transparency support. Once it becomes clear, if any new opportunities for road graphics are opened up, or not, I'll pick this up again. Even if the answer is "no" there might be some smaller improvements possible as to texture and coloring.


Being no programmer, I apologize for all my suggestions that imply undue workload and for other misjudgements due to lack of expertise or relevant skills.
I am on Win32, have no means to compile, and rely on prefabricated distributions (Thanks to Tino).

Top Quote
SirVer
Joined: 2009-02-19, 17:18
Posts: 1324
Ranking
One Elder of Players
Location: Germany - Munich
Posted at: 2011-11-10, 11:36

Note that shevonar takes a shot at improving the !OpenGL renderer. As a side effect, better road display at least for !OpenGL might fall out.

Edited: 2011-11-10, 11:37
Top Quote
ixprefect
Joined: 2009-02-27, 16:28
Posts: 367
Ranking
Tribe Member
Posted at: 2011-11-28, 21:58

So... in an OpenGL-only world, here's how road rendering should ideally work in my opinion.

There are RGBA road textures of size Lx8, where the width L can be any power of two, but the height of the texture is fixed at 8. This corresponds to the width of the roads, of course. The terrain renderer selects which texture to use based on the type of road (normal or busy) and the underlying terrain. It then just uses OpenGL to set up the transforms such that everything works out as it should.

As an optimization, the renderer can combine all road textures into a single texture during loading, as long as the width L is the same for all of them (I would suggest something reasonable like 128). This limits texture switches, which are one of the great sources of inefficiency with OpenGL. But that's really an implementation detail.

This should satisfy all your wishes and would be a nice improvement, I think.

And then there's the software renderer. All of this can be done in the software renderer as well, but it would be more painful. We do not have existing code to do alpha blending - the blending of animations is done by SDL itself. This would have to be written for both 32 bits and 16 bits (ugh.. is there even anybody left who still uses that?).

It would help the software renderer if the road textures were palette images instead of RGBA, with a simple colour key, i.e. one dedicated colour (palette index) corresponds to completely transparent, everything else is completely opaque.

If we want to keep having the same visuals in both software rendering and OpenGL (which would be nice), a compromise would be to drop 16 bit support, and add 32 bit blending to the road rendering. That can be done reasonably, without worrying too much about the headaches involved in unpacking and packing 16 bit pixel data.


Top Quote
Astuur
Avatar
Joined: 2009-02-28, 12:08
Posts: 733
Ranking
One Elder of Players
Location: Frankfurt / Germany
Posted at: 2011-11-29, 09:01

Okay, thanks very much, Ixprefect.
Trying to summarize what I have understood:

On the OpenGL side, alpha blending is not supported currently, but you are seeing a way to implement it.
A precondition for that is that the width of the roads should be limited to a fixed 8Px.
I would have hoped for something a bit wider than that, to have some freedom for border variation, but it will do.
OpenGL would then allow that road texture can adapt to the underlying terrain.
Seen from the graphic side, this would open up so many options for the road system, that waiting for such an implementation seems very worthwhile.

Ixprefect, would you please be so kind as to write down your idea, as a suggestion on the bugtracker, a blueprint, or whatever, at a place and in a form that it won't be lost, and other programmers understand your concept?

The SDL side will be a lot harder to fix if the same functionality needs to be supported.
This is espicially true, if the support for 16bit color mode must be retained.
(A palleted image with one fully transparent color, would be no match for the OpenGl side but a severe limitation and effectivly forbid most techniques.)

In the light of a fading importance of the SDL rendering, see https://bugs.launchpad.net/widelands/+bug/887093,
I personally would not have a problem to accept that the full beauty of the roads only comes with OpenGl, much less with
the suggestion that 16bit color modes should no longer be supported.
However, all of this is not for me to decide, instead, the guys with the master plan - most prominently SirVer - are kindly asked to speak up on this topic.

Other than that -- is there anyone interested and capable (as in "skill" and "spare time") to actually make Ixprefects ideas come alive?


Being no programmer, I apologize for all my suggestions that imply undue workload and for other misjudgements due to lack of expertise or relevant skills.
I am on Win32, have no means to compile, and rely on prefabricated distributions (Thanks to Tino).

Top Quote
ixprefect
Joined: 2009-02-27, 16:28
Posts: 367
Ranking
Tribe Member
Posted at: 2011-11-29, 13:21

To clarify: the 8px was just based on the fact that the roads are currently 5px wide. We could go for 16px as well. The only constraint is that for practical OpenGL-related purposes it should be a power of two, since some (admittedly by now quite old) hardware can only support that.

Though, now that I think about it, we could even consider dropping that if we merge the road textures into a single OpenGL texture on load anyway. Then the only constraint is that all the road textures should have the same length.

After having slept on it a bit more, I would vote for full RGBA support, implementing it in both OpenGL and software, and dropping 16 bit support.


Top Quote