:: Home :: Get Hosted :: PPM FAQ :: Forum FAQ :: Search :: Memberlist :: Usergroups :: Register :: Profile :: Log in to check your private messages :: Log in ::
Do you want to advertise at Project Perfect Mod. Find out how to do it HERE.

The time now is Tue Sep 19, 2017 7:06 pm
All times are UTC + 0
 Forum index » Modding Central » OpenRA Editing Forums
disable/fix cumulating shadows
Moderators: Global Moderators, OpenRA Moderators
Post new topic   Reply to topic Page 1 of 1 [27 Posts] View previous topic :: View next topic
Author Message
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Mon Aug 29, 2016 12:57 pm    Post subject:   disable/fix cumulating shadows Reply with quote

A problem which have already the classic C&Cs, but which is imo more prominent now in OpenRA are cumulating shadows.
2 shadows over each other causing an even darker shadow where they overlap each other.

Since OpenRA allows one unit to cast shadows from multiple parts of the unit, it is more likely that they overlap each other and thus more prominent in this engine.
e.g.
Titan body + voxel barrel shadow
Heli + rotor with both casting shadows


I think it would a nice graphical improvement if OpenRA has this fixed.
Though i also see that this might be a rather difficult task, depending on how the engine renders the objects,
since for such a job it would first have to collect all object shadows, create a single shadow map and then only render that single shadow map.
_________________
SHP Artist of Twisted Insurrection. Main Nod building SHP creator.

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant unit, 1 Scrin unit, 1 GDI building

Tools
TMP Shop
C&C Executable Modifier

Back to top
View user's profile Send private message
Graion Dilach
Defense Minister


Joined: 22 Nov 2010
Location: Iszkaszentgyörgy, Hungary

PostPosted: Mon Aug 29, 2016 2:02 pm    Post subject: Reply with quote

There is an OpenRA bugtracker already. Please refrain using this forum as such - the actual issue tracker can be updated properly with the status of a bug.

This is actually already reported there - https://github.com/OpenRA/OpenRA/issues/6019 - and it's not just shadows which are affected, but alpha or overlay rendering as well.
_________________



AS Discord server: https://discord.gg/7aM7Hm2

Back to top
View user's profile Send private message MSN Messenger
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Mon Aug 29, 2016 5:44 pm    Post subject: Reply with quote

I don't see a problem with discussing issues here.  It's better than the probable alternative of no discussion happening at all.

This can't be fixed with the current renderer setup, but it should be possible once the TS rendering overhaul is completely finished.  That will probably be another year or more at the current rate of progress, so don't hold your breath.

Back to top
View user's profile Send private message
Graion Dilach
Defense Minister


Joined: 22 Nov 2010
Location: Iszkaszentgyörgy, Hungary

PostPosted: Mon Aug 29, 2016 7:26 pm    Post subject: Reply with quote

Please advertize that you want to dumb down the voxel renderer to Westwood quality by restoring the VPL and don't accept any other option at all as part of that rendering overhaul.
_________________



AS Discord server: https://discord.gg/7aM7Hm2

Back to top
View user's profile Send private message MSN Messenger
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Mon Aug 29, 2016 9:38 pm    Post subject: Reply with quote

Graion Dilach wrote:
Please advertize that you want to dumb down the voxel renderer to Westwood quality by restoring the VPL and don't accept any other option at all as part of that rendering overhaul.


Sure, my pleasure. I'll quote this post from the start of last year:

pchote wrote:
It all comes down to performance.  The current voxel renderer performance scales as roughly [2*(<voxel width> + <length> + <height>) + large constant] times slower than rendering a sprite: in practice, 100 ~ 1000 times slower.  Rendering a sprite is very fast, but ~500 x <fast> x <a bunch of voxels> adds up to a lot of GPU/CPU time that could be better spent doing other things.  By changing the way we do the rendering we may be able to win a factor of 10 improvement, which means 10 x more units could be rendered on screen (note: not quite that simple in reality) before performance drops.


We're making a game, not an asset viewer, and sometimes that means making tough trade-offs if we want to ship something this decade.  Using the VPL to software-blit into a scratch texture is an option that should give better performance than the current approach while avoiding the problem of not being able to squeeze 5 channels of pixel data into a 4 channel texture.

I'm happy to accept alternative options but so far nobody else has given any aside from the four that I posted in the PR you are referring to.  "No, I don't want you to do that" is not an option, because it does nothing to solve the problems at hand.  The most likely short term solution is the one that sacrifices even more performance to fix our texture space problem without requiring the VPL.  My own personal opinion is that the VPL is indeed the best long term tradeoff between perfomance, development effort, and flexibility because a less flexible solution that actually gets released and is playable is better than something that is infinitely flexible but never finished.

Last edited by pchote on Mon Aug 29, 2016 10:05 pm; edited 1 time in total

Back to top
View user's profile Send private message
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Mon Aug 29, 2016 10:02 pm    Post subject: Reply with quote

I haven't tested a mod with voxels yet, but is the performance drop really that noticeable?

Since nowadays RAM is present in excessive amounts, wouldn't something like a pre-rendering into temporary sprites work?
If you render for all voxels a 32 facing sprite during map loading, you would reduce the amount of render work for about 80-90% of the ingame shown voxel.
For the rare cases of a tilting voxel (which usually also don't last long), the engine could fall back on the direct voxel rendering using the current system.
Wouldn't that be a good compromise of quality and performance?


Though if performance improvement is really that much higher with a VPL, i wouldn't mind such a logic.
In OpenRA it would be surely possible to fix a few things that are currently ruining Voxels in the WW C&Cs way of VPL rendering, like the bad light direction, giving voxels more light from the side than from top.

Maybe both renderer could be implemented later and offered for the user to chose from in the graphics menu. Then it's up to the user and his high-end power machine to have high quality voxel rendering or the weak machine to use the fast VPL renderer.
_________________
SHP Artist of Twisted Insurrection. Main Nod building SHP creator.

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant unit, 1 Scrin unit, 1 GDI building

Tools
TMP Shop
C&C Executable Modifier

Back to top
View user's profile Send private message
Graion Dilach
Defense Minister


Joined: 22 Nov 2010
Location: Iszkaszentgyörgy, Hungary

PostPosted: Tue Aug 30, 2016 5:42 am    Post subject: Reply with quote

The perf drop is noticable. I give him that.

Involving the VPL would already mean prerendering into sprites. The thing is, that the VPL is "benefical" because it keeps the 256 colors per sprite option by forcing one to reuse the same 256 colors on all 32 tables. I don't think dynamic lighting can stay at VPL usage either since the VPL works with fixed tables as well.

Keep in mind, how pchote fixed me on the other day that palette switching "isn't" a problem. Well, here it apparently is, because even rendering 16/32 sprites on top of each other - with the VPL being a palette table instead of the VPL - is bad.

Also, OpenRA uses the VRAM for storing textures.
_________________



AS Discord server: https://discord.gg/7aM7Hm2

Back to top
View user's profile Send private message MSN Messenger
G-E
General


Joined: 09 Feb 2015

PostPosted: Tue Aug 30, 2016 7:01 am    Post subject: Reply with quote

I suggested a pre-rendering pass when loading a new mod to do just that LKO, I don't remember why they shot me down, something about load time I think. Honestly if voxel performance is going to continue to flounder, then why not convert them to sprites and cache them?

AND if they are pre-rendered, then additional beautifying tricks like proper raytraced lighting with occlusion and reflectivity could be added with only 1-time penalty... until you change the mod or force it to rebuild the cache with a new command.
_________________
http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai

Back to top
View user's profile Send private message
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Tue Aug 30, 2016 12:12 pm    Post subject: Reply with quote

It's time for a lesson in GPU programming.  Take notes, because this may be in the end-of-year exam Wink

Sprite data isn't stored in RAM, but in VRAM on the GPU, which most machines have considerably less of (especially people with integrated GPUs).  Our TS mod is already running near the limits of low-end chips that are otherwise perfectly capable of running OpenRA.  The third party mods built by others that use giant sprites with hundreds of frames and other effects blow right past those limits to the holy-crap-Nth-degree.

On modern computer hardware you can't just blit pixels directly into the screen buffer.  You instead have to load texture and vertex data onto the GPU and then have that run its own specially written programs (called shaders) that transform that data into the images that get sent to the screen.

The core of OpenRA's renderer emulates the "old world" design for blitting sprites to the screen using specially packaged vertex and texture data that is processed by specially written shader programs.  The important details here are that the indexed (1-channel) sprites are loaded into large sprite sheets, with each 4-channel (RGBA) pixel holding data for 4 independent 1-channel sprites.  These sprite atlases tell you what color index should be used for each pixel, but not what palette is used.  The palette reference is encoded in the vertex data, which means that each indexed sprite can only use colors from a single palette.  Any suggestions about using different palettes for different pixels within a sprite are immediately and completely infeasible (sorry Graion).

We also support RGBA sprites (mostly used for the UI, but also for voxels and the floating text displays), and polygons filled with colors (for lasers, selection boxes, etc etc).  Each time we change from rendering an indexed sprite to one of these other types of drawing (or back) the GPU and CPU (which normally run in parallel) need to stop and resync, switch state, then continue.  In our renderer-speak this is "breaking a batch", and so large batch counts are generally going to mean worse performance.

Most of the work in implementing the per-pixel depth rendering has gone into rewriting our indexed sprite renderer to accept and use 2-channel (palette+depth) sprites.

Voxels, being defined in 3D, don't fit this sprite rendering model at all.  Instead, we have a pre-rendering pass that takes all of the voxels on the screen each frame and renders them into an intermediate RGBA buffer (with all the lighting calculations being self contained here).  The resulting RGBA sprites are then drawn in the world normally (the renderer has no idea that they came from voxels).

This approach has three problems:
  1. RBGA sprites require the context switch described above, so scenes that mix many voxels and sprites are going to have large performance overheads.

  2. Rendering out RGBA in the first pass uses all of our texture channels, so we have nowhere to store the depth data.  We can't composite these sprites correctly with the rest of the depth-enabled world.

  3. Caching voxel data on the GPU uses four times as much VRAM as normal sprites (twice as much as sprites with depth data), and we would still need to pay the cost of switching shader programs when rendering them.  This more than kills any benefits that could come from prerendering common facings.

Problem #2 is the real killer here: prerendering can't help (because we can't store all the data we need), and going the opposite way we can't solve this by doing everything in the second pass (this introduces another set of issues when using translucent palettes).

If we used the VPL for resolving the lighting then the output from the first render pass could be a normal 2-channel indexed+depth sprite.  We could then composite them in the world without the context-switch overheads, plus it fixes the depth data issue and halves the VRAM usage vs our current approach.

The other approach that I have referred to several times now is to change the first render pass to output (<palette index><normal index><depth offset><wasted space>) instead of (RGBA), and then do the palette resolution and dynamic lighting during the second pass of rendering.  This lets us use the depth data, but misses the other benefits from the VPL.  This will be slower than the current rendering because we can no longer merge voxels with different palettes (remember that the palette reference is stored on the vertex data, so we need a different set of vertices for each palette), so we have to use more texture space to render out the different parts and then deal with more context switches to render them in the second pass.  The extra overhead of doing the lighting calculations in the second path is non-zero but probably negligible.

There are other approaches, some of them technically better than these two, but they require much more developer effort and time to do.

Last edited by pchote on Tue Aug 30, 2016 12:36 pm; edited 1 time in total

Back to top
View user's profile Send private message
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Tue Aug 30, 2016 12:21 pm    Post subject: Reply with quote

Ok, i'm out of suggesting anything. That's too high for me. Confused
_________________
SHP Artist of Twisted Insurrection. Main Nod building SHP creator.

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant unit, 1 Scrin unit, 1 GDI building

Tools
TMP Shop
C&C Executable Modifier

Back to top
View user's profile Send private message
Graion Dilach
Defense Minister


Joined: 22 Nov 2010
Location: Iszkaszentgyörgy, Hungary

PostPosted: Tue Aug 30, 2016 1:53 pm    Post subject: Reply with quote

pchote wrote:
Sprite data isn't stored in RAM, but in VRAM on the GPU, which most machines have considerably less of (especially people with integrated GPUs).  Our TS mod is already running near the limits of low-end chips that are otherwise perfectly capable of running OpenRA.  The third party mods built by others that use giant sprites with hundreds of frames and other effects blow right past those limits to the holy-crap-Nth-degree.


Reality is quite amusing though: it moreso seems that VRAM amount isn't a problem, and sprite sheet sizes are (since a sprite sheet is pretty much a texture). For reference: currently I'm using an Intel HD 2000 (i5-2500 - not 2500k) GPU which supposed to have 64 MB VRAM.

Note that I'm using the YR Terrain Expansion theaters which requires a 4096x4096 texture size, which is 64 MB VRAM itself (4096x4096=16M*4 channels = 64M) (oh and just checked, I have depthmap enabled for ages now, so prolly more). I did crash on snow and newurban terrains, but indeed, those are bigger and require 8k or 16k texture sizes.

On Windows, I crashed with out-of-memory errors as expected, but since I jumped to Linux, my OpenGL driver went down from 3.3 to 3.0, but I don't have VRAM crashes - as you implied back then in the issue I opened about my Win driver leaking VRAM. My Radeon HD3000 driver experiences - where they exist, so Win7/Win10/Kubuntu 12.04.1 - also matches my Intel HD2000-on-Linux experiences.

TLDR: It appears nowadays technology lets you page VRAM as you can page RAM. But then you have to maintain pagesizes which are manageable and everything but tilesets can do that. I even go on and outright state that Penev's ominous black RA2 terrain was a case of paged tileset sheet.

pchote wrote:
The palette reference is encoded in the vertex data, which means that each indexed sprite can only use colors from a single palette.  Any suggestions about using different palettes for different pixels within a sprite are immediately and completely infeasible (sorry Graion).


I gave up talking about individual sprites like how you imply the first time you explained this to me. Note that I explicitly mentioned 16/32 sprites here and I aslready suggested this exact thing the last time, even. Creating a sprite from each used VPL tables and putting them on top of each other lets you maintain the one-palette-on-the-single-sprite rule, while still letting you do everything you supposed to. (You coulda even make this easier, by having the depth as a 17th/33th layer and not creating the depth layer per each layer). Yes, it's inefficient on texture space, but again, I don't believe the out-of-VRAM issue exists as much as you imply, mostly because, again, I am actively modding on systems with VRAM your logic outright states I should crash during loading.

Fun fact: if you go through the VPL research topic, there are tests by people which imply WW also did what I suggest, since decreasing the used table count will prevent the rendering of the sides which would have used those tables, but still keeping shadow - which might be a bonus layer rendered under the voxel.

Doing that would still let the voxel colors be dynamic in a sense - okay, fake lighting, since the pal is a generated table - which is already a bonus compared to the WW lighting. I'm fine with taking compromises, but you so far don't offer one.
_________________



AS Discord server: https://discord.gg/7aM7Hm2

Back to top
View user's profile Send private message MSN Messenger
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Tue Aug 30, 2016 2:05 pm    Post subject: Reply with quote

That isn't a compromise, it's a dirty hack.

Back to top
View user's profile Send private message
E1 Elite
Plasma Trooper


Joined: 28 May 2013

PostPosted: Tue Aug 30, 2016 4:55 pm    Post subject: Reply with quote

Graion Dilach wrote:
I'm using an Intel HD 2000 (i5-2500 - not 2500k) GPU which supposed to have 64 MB VRAM.

Usually in BIOS of desktops, shared memory from available RAM can be allocated to
integrated graphics. Yours might have upto 512mb.

Back to top
View user's profile Send private message
Graion Dilach
Defense Minister


Joined: 22 Nov 2010
Location: Iszkaszentgyörgy, Hungary

PostPosted: Tue Aug 30, 2016 6:14 pm    Post subject: Reply with quote

Not in this generation/hardware for sure. Already went through the UEFI looking for that option. I was told there is a way to do it, but that involves overloading a memory channel that way (with the risk of it being burnt out) and I decided to not take that risk.
_________________



AS Discord server: https://discord.gg/7aM7Hm2

Back to top
View user's profile Send private message MSN Messenger
Bittah Commander
Defense Minister


Joined: 21 May 2003
Location: The Netherlands

PostPosted: Tue Aug 30, 2016 7:50 pm    Post subject: Reply with quote

If I'm understanding pchote right, having either only SHPs or only voxels in a mod would have a lot better performance than having both.
So does that mean that if voxels were converted to SHPs that include 8 tilt angles with 32 facings for both the main body and turret, the performance would be better? I'm aware that the amount of frames could accumulate to extreme amounts (especially when there's animations involved), but let's just assume that disk space is not an issue.
_________________

Back to top
View user's profile Send private message Send e-mail MSN Messenger
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Tue Aug 30, 2016 8:13 pm    Post subject: Reply with quote

That approach keeps the main disadvantage of using the vpl (you're still stuck with the color indices from your chosen palette for all facings), but then adds a bunch more.  It would be much better to just fix the voxel rendering.

Back to top
View user's profile Send private message
G-E
General


Joined: 09 Feb 2015

PostPosted: Wed Aug 31, 2016 1:15 am    Post subject: Reply with quote

Ok so pchote, if the engine renders each voxel into a sprite each refresh cycle, why wouldn't a single rendering pass to pre-render 64 facings when the mod loads not make sense? You'd have voxel compatibility without breaking the engine.

If you already have the units available as sprites, you can load those into ram, and swap them in and out of vram as necessary no? The throughput should be enough for this compared to cyclical rendering... especially if anim overlays are cumulative rather than specular, because we aren't raytracing to need dynamic facing based lighting updates on the pre-rendered sprites.

Besides all that, I don't think aiming ORA at the lowest of the low hardware makes sense when it comes to mods. If I release a super graphics heavy mod that can only run on 4ghz cpus with 12gb video cards, that's my problem, and I can write a disclaimer.
_________________
http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai

Back to top
View user's profile Send private message
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Wed Aug 31, 2016 7:58 am    Post subject: Reply with quote

My detailed reply above has already explained why that doesn't help the current situation.  That would only be feasible as a secondary optimization after an initial rewrite changes the rendered sprites to be paletted instead of RGBA.

Back to top
View user's profile Send private message
Bittah Commander
Defense Minister


Joined: 21 May 2003
Location: The Netherlands

PostPosted: Wed Aug 31, 2016 2:16 pm    Post subject: Reply with quote

Bittah Commander wrote:
So does that mean that if voxels were converted to SHPs that include 8 tilt angles with 32 facings for both the main body and turret, the performance would be better?

pchote wrote:
That approach keeps the main disadvantage of using the vpl (you're still stuck with the color indices from your chosen palette for all facings), but then adds a bunch more.  It would be much better to just fix the voxel rendering.

If that was a reply to my post, I don't see how the vpl is still relevant if all voxels would be converted to SHPs with tilt frames. This means that you'd then have no voxels at all (=no vpl) and thus context switching, which should give better performance despite the fact that some SHPs will then have a a lot of frames, right?
_________________

Back to top
View user's profile Send private message Send e-mail MSN Messenger
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Wed Aug 31, 2016 2:31 pm    Post subject: Reply with quote

i think he means that a voxel when currently rendered is turned into an RGBA image.
If that would be converted again into an indexed palette SHP kind of temporary graphic, several advantages of the RGBA would be lost, not to speak of the quite time consuming job to convert an RGBA image into an indexed palette image, where certain information can get lost or turn out wrong (e.g. red pixel turned into remap)

Though there is surely a way to avoid such issues by using custom palettes for such temporary SHPs.
_________________
SHP Artist of Twisted Insurrection. Main Nod building SHP creator.

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant unit, 1 Scrin unit, 1 GDI building

Tools
TMP Shop
C&C Executable Modifier

Back to top
View user's profile Send private message
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Wed Aug 31, 2016 3:22 pm    Post subject: Reply with quote

Please read my detailed post above and try to understand it.  Both of your comments are based off incorrect assumptions that are directly contradicted by what I wrote.

I put a lot of effort into explaining exactly what the engine does and the implications of that primarily because i'm getting a bit tired of repeating the same key points over and over in slightly different ways.

Back to top
View user's profile Send private message
Lin Kuei Ominae
Seth


Joined: 16 Aug 2006
Location: Germany

PostPosted: Wed Aug 31, 2016 5:45 pm    Post subject: Reply with quote

i don't see how we are that wrong.

You wrote that all voxel on the screen are rendered into an rgba buffer, which to get rendered needs the "breaking a batch" step which is slow.

We on the other hand suggest to create for each voxel, during map load (not ingame) a 32 facing sprite beforehand, which is used during the game instead of sending the voxel into the voxel renderer.

So for each voxel the engine does something like this
if (IsPrerenderedSprite4VoxelAvailable(voxel, voxel.angle))
then
 GetSprite4Voxel(voxel, voxel.angle) and send sprite into the fast sprite renderer
else
 send voxel into the slow voxel renderer

in the next step the engine would use as you described the sprites and the RGBA image of the voxel renderer to create the final image.
But with the reduced work for the voxel renderer, the step to create the RGBA buffered sprites for each voxel would be done faster.

In the best case, all voxel on the screen have a prerendered sprite available (just like an SHP), so the voxel renderer doesn't has to do anything
and everything is done by the faster sprite renderer only.
_________________
SHP Artist of Twisted Insurrection. Main Nod building SHP creator.

Public SHPs
X-Mech Calendar (28 Mechs for GDI and Nod)
5 GDI, 5 Nod, 1 Mutant unit, 1 Scrin unit, 1 GDI building

Tools
TMP Shop
C&C Executable Modifier

Back to top
View user's profile Send private message
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Wed Aug 31, 2016 6:14 pm    Post subject: Reply with quote

pchote wrote:

[snip]

2. Rendering out RGBA in the first pass uses all of our texture channels, so we have nowhere to store the depth data.  We can't composite these sprites correctly with the rest of the depth-enabled world.

[snip]

Problem #2 is the real killer here: prerendering can't help (because we can't store all the data we need)


The fixes for this problem are to either:
  • use the VPL to render out an indexed sprite + depth that can be rendered using the fast sprite renderer.
  • Render out less data in the first step and do the rest in the second pass, which can't use the fast sprite renderer.


Pre-rendering data has at best a secondary effect in all this.  I'm not saying that it wouldn't help performance, but that it doesn't solve any problems on its own so isn't particularly relevant to the topic.  If we're forced to go with the second option because the community would otherwise have a meltdown then I certainly won't be spending any of my time implementing prerendering, because even with that our best-case performance would still very likely be worse than using indexed sprites without caching.

Using the indexed sprites combined with pre-caching would indeed make rendering effectively free in some situations, but again this would depend on the vpl-based rendering being done first.

Back to top
View user's profile Send private message
Bittah Commander
Defense Minister


Joined: 21 May 2003
Location: The Netherlands

PostPosted: Wed Aug 31, 2016 11:48 pm    Post subject: Reply with quote

I think you and/or LKO might have misunderstood me. My suggestion wasn't for the game itself to temporarily convert voxels to SHPs on the fly, but for all voxels to be converted to actual SHP files (with tilt frames) externally so that the game won't have any voxels to deal with in the first place.

While a VPL would indeed still have to be used for the conversion process, the final result would be SHPs that look just like voxels ingame, with only the visual disadvantage of a less smooth transition to the tilted angle when the unit moves onto a ramp (since there'd only be a single tilt pitch angle). The visual benefit on the other hand would be that units that are directly created as such SHPs with tilt angles would look a lot better than a voxel could ever look.

It's already established that having only SHPs and no voxels in the game gives a lot better performance, so my question from before was basically whether having many SHPs with tons of frames (because of having tilt angles + turrets and/or animations) would still give better performance than having mixed voxels and SHPs (with much fewer frames).
_________________

Back to top
View user's profile Send private message Send e-mail MSN Messenger
G-E
General


Joined: 09 Feb 2015

PostPosted: Thu Sep 01, 2016 3:12 am    Post subject: Reply with quote

That's more or less what I said too, pre-render and save the sprites to a cache. You'd only have to rebuilt the cache when the mod or units are altered anyway, so this one time processing fee becomes irrelevant.
pchote wrote:

Problem #2 is the real killer here: prerendering can't help (because we can't store all the data we need)

This seems like a silly argument, if a mod uses voxels then they slow down with rendering, and people will tend to make .shp art instead. If the game can't handle a cache of all pre-rendered voxel units because there isn't enough "vram", why would it be any different if the mod author makes the .shp units themselves?
_________________
http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai

Back to top
View user's profile Send private message
pchote
Cyborg Soldier


Joined: 06 Feb 2015

PostPosted: Thu Sep 01, 2016 6:35 am    Post subject: Reply with quote

Sure, mods can do that if they want, but that then has nothing to do with rendering voxels in TS, RA2, or other mods that still want to use them.

G-E wrote:
If the game can't handle a cache of all pre-rendered voxel units because there isn't enough "vram", why would it be any different if the mod author makes the .shp units themselves?
The number of channels in a texture (R, G, B, A = 4) has nothing to do with the amount of VRAM on the GPU.  The point that you guys keep on missing is that the first limitation, which is what forces the rewrite, is on texture channels, not memory.  The amount of memory is a secondary issue that then comes into the choice of how to resolve that first issue.
Back to top
View user's profile Send private message
G-E
General


Joined: 09 Feb 2015

PostPosted: Fri Sep 02, 2016 5:53 am    Post subject: Reply with quote

You mean you're trying to make 2D sprites with simulated 3D mapping from a voxel, as a way to help the engine handle occlusion/height/etc, because the modern shader based video card can't handle static 2D sprites directly?

If I got that right, explain to me why pre-rendered (ie. all facings rendered with rules based lighting already) can't be loaded onto flat/front-facing 3D objects like a video texture?
_________________
http://www.moddb.com/mods/scorched-earth-ra2-mod-with-smart-ai

Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic Page 1 of 1 [27 Posts] View previous topic :: View next topic
 Forum index » Modding Central » OpenRA Editing Forums
Jump to:  
Quick Reply
Username:


If you are visually impaired or cannot otherwise play the game below please contact the Administrator for help.


 
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © phpBB Group

Wildcard SSL Certificates
[ Time: 0.2891s ][ Queries: 12 (0.0312s) ][ Debug on ]