Our ReVolt Pub

Hi, I have some suggestions regarding the texturing method used in Re-Volt tracks at this moment :

- Use more than 10 textures
- Disable clamping
- Support other texturing format than BMP
- Remove the restriction of «Perfect Square» textures introduced in v1.2


I hate to tell that my 2 first suggestions seems to be a issue that only affects me at this time, but these are fustrating restrictions of Re-Volt that disallow me to convert tracks from other racing games.

As I know, lots of games uses UV mapping values that are outside the range of 0 and 1. This is used to repeat the texture on the same polygon instead of creating another polygon on each 1 unit. Also, to ensure the texture is repeated correctly, texture clamping is disable, so it avoids stretching the texture as it's shown below.


Clamping Enabled


Claming Disabled

As for the limit of 10, majority of games uses more than this number (sometimes more than 200). I know it's possible to put some textures in one, but this technique cannot be used due to the uses of UV values outside 0 and 1 (as I mentioned before).


It's a lot complicated to explain textually, I know...

These suggestions can be applied on RVGL too.

- Use more than 10 textures

You can use textures bigger than 256x256, so this isn't really a limitation anymore.

- Support other texturing format than BMP

Why?

- Remove the restriction of «Perfect Square» textures introduced in v1.2

That restriction was necessary in order to make 512/1024/2048/4096 textures possible in v1.2. Again, why do you want this removed?

As I know, lots of games uses UV mapping values that are outside the range of 0 and 1.

There are plenty of ways of avoiding these sorts of mapping limitations for the game. The grill texture for an upcoming conversion of mine was originally mapped the same way. This was the original texture for it:



I simply made it a bigger texture to replicate how the texture looked like in the original game.




It would take more effort for the developers to fix those limitations you mentioned than for us to figure out ways around those limitations.

but these are frustrating restrictions of Re-Volt that disallow me to convert tracks from other racing games.

Do you have all the textures? Do you have enough reference pictures to know where each texture belongs in the track? If so, what's stopping you from manually mapping the track yourself?

You can use textures bigger than 256x256, so this isn't really a limitation anymore.

4096px is not suffisant in this case, there's so many texture that use the «outside 0 and 1 method» it will not work anyway

- Support other texturing format than BMP

Why?

Because a 4096px BMP is 48 MB (!!!) Too heavy. If you have 10 texture of 4096, then your folder will be 480 MB, which is just ridiculous.

That restriction was necessary in order to make 512/1024/2048/4096 textures possible in v1.2. Again, why do you want this removed?

Yeah, this is not really important finally...

There are plenty of ways of avoiding these sorts mapping limitations for the game. The grill texture for an upcoming conversion of mine was originally mapped the same way. This was the original texture for it:

In your case, it's the perfect choice, I agree. You can easly repeat a 16px texture.
In my case, you have at least 250 textures of 128px or more that you have to repeat at least 30 times. So it's theorically not possible.

R2049 Melee track which have a total of 25 different textures (see WIP in RVL) already uses 3 textures of 1024px. Just think of those track who have about 300.

[...] If so, what's stopping you from manually mapping the track yourself?

It's not just remaping. I have to recreate all 87000 polys of the track to remap correctly...

It would take more effort for the developers to fix those limitations you mentioned than for us to figure out ways around the limitations.

I know that maybe it will not be possible to do so, it's just a suggestion to modernize Re-Volt.

I will have soon another more easier suggestion.

4096px is not suffisant in this case, there's so many texture that use the «outside 0 and 1 method» it will not work anyway

Because a 4096px BMP is 48 MB (!!!) Too heavy. If you have 10 texture of 4096, then your folder will be 480 MB, which is just ridiculous.

R2049 Melee track which have a total of 25 different textures (see WIP in RVL) already uses 3 textures of 1024px. Just think of those track who have about 300.

You're not going to get anything done with that attitude. At least provide some screenshots so I have an idea on what you're on about.

It's not just remaping. I have to recreate all 87000 polys of the track to remap correctly...

The solid poly limit for RV is 65k. Do you want Huki and Jigebren to up the poly limit too?

nero @ 14 Jun 2015, 06:59 PM wrote: The solid poly limit for RV is 65k. Do you want Huki and Jigebren to up the poly limit too?

The world geometry poly limit is virtually unlimited (at least in the file structure), I don't know if there is a limit in that range regarding displaying that many polygons at the same time on the screen but if thats the case then you're doing something wrong in your track anyways.

What you probably mean is the collision polygon (.ncp) limit which is indeed 65k (even half for old versions) which is a restriction of the file structure.

But considering the fact that these polygons are not visible to the player and only need to be placed on the parts where you want the cars to race, these will end up being in the smaller range than the visual geometry and it should generally be possible to stay within that range (might require some optimization and a few cuts in the track here and there if it really should get close to the limit).

4096px is not suffisant in this case, there's so many texture that use the «outside 0 and 1 method» it will not work anyway

4096x4096x10 px is not enough space for every texture that you want to include in the track?

No offense but you might want to reconsider your design, the original developers were able to work with 256+ times less space than that and still managed to make incredible scenery.

And if you're aiming for some "ultra high definition" quality - trust me, that gets meaningless pretty quick.
I would rather focus on a good track flow and believable scenery, unfortunately most custom tracks lack both.

Kenny @ 14 Jun 2015, 07:58 PM wrote: What you probably mean is the collision polygon (.ncp) limit which is indeed 65k (even half for old versions) which is a restriction of the file structure.

That's what I was referring to; tracks can have a maximum solid polygon limit of 65k. I'm not quite sure what the limit is for non-solid polygons.

Kenny wrote:4096x4096x10 px is not enough space for every texture that you want to include in the track?

Hard to beleive but... no, cause of the «very very very too much» «repeated texture» mentioned before

Nero wrote:You're not going to get anything done with that attitude. At least provide some screenshots so I have an idea on what you're on about.

Sorry I didn't want to offense anyone. It's hard to prove my neutrality in text.

Anyway I will just forget about this and everybody will be happy
Thanks guys for the advices

nero @ 14 Jun 2015, 09:07 PM wrote: That's what I was referring to; tracks can have a maximum solid polygon limit of 65k. I'm not quite sure what the limit is for non-solid polygons.

Yes, but Dyspro50 was talking about the .w files, therefore the .ncp limit doesn't (directly) apply.

About the polygon limit of the .w files:
- generally you have your track cut in "Cubes" which is pretty much just a collection of (un)textured polygons grouped together

- one cube can hold 32.5k polygons (I don't think they upped this to 65k in 1.2)

- you can store ~2.1*10^9 cubes (could be upped to ~4.3*10^9 but I don't think they did this in 1.2 either)

- this makes it theoratically possible to store up to ~7*10^14 polygons for one .w file

Assuming that one polygon takes 1 byte of memory space (which it doesn't), you'd end up with over 70TB of space that needs to be allocated for the whole world to be stored and loaded.
As you can see you'd hit other limits without even getting close to that limit, thats why I said "virtually unlimited"

As for a practical limit, thats hard to tell since it depends on a lot of factors (primarily how well your track is optimized) but I'd recommend to use the ncp limit as a reference point anyway (perhaps twice that if you have a lot of parts in your track that are not meant to be accessed by the cars) since:
1) if you go well beyond that you most likely get into trouble with the ncp limit

2) its never a good idea to completely ignore performance and just aim for maximum detail, in the end you'll probably just end up with a laggy track

I'm not going to comment on the other stuff, but for not-bmp images specifically PNG for RVGL is definitely on the roadmap.

And high time too, even currently the apparent difficulty of working with 32-bit bitmaps holds some people back. r6te logo in industry

^This has been puzzling me for a while - in Photoshop you can work/edit/whatever 32-bit BMPs so easily it hurts. I've been doing it for years.

Is this a question of "avoiding installing another tool just for a single purpose" or something else?... By the way, what image editing program do you use? (from my experience, PS is superior in most aspects than, lets say, GIMP or Paint.Net)

Gimp, gimp all the way

Technically I could probably get PS working in virtualbox, but aquiring it through one means or another just isn't worth the effort when a program that actually runs on my platform fits my needs perfectly fine.


In any case with Gimp the process for 32-bit bitmaps isn't even different, just open the 'advanced options' toggle when exporting and check the first 32-bit option.

Photoshop automatically opens a window for you to choose from 16, 24 and 32 bits upon choosing to save in the bmp format. ;P

I've had limited experience with GIMP, I reckon there must be some aspects where it ends up being better than Photoshop. I just always grew familiar with PS and so far it's satisfied my repaint needs.

A bit related with this topic, I read somewhere that bmps load slower than PNGs - I always thought that PNGs were more on the "heavy side"?...

Depends on the hardware - BMPs are larger in size while PNGs are compressed in some manner. The decompression is small beans for modern cpus/gpus/whatever, while load times are still a bottleneck for people without SSDs.

(also explained/discussed in that same linked post )

If you want to use png, jpg or <insert open format> then move to rvgl..

Yes, BMP are heavy as holy god, make yourself a blank image with different sizes and go trough all the formats, you'll see that png is fair play but clear winner is jpg. (it's like picking between 7z, rar and zip or cab)

DDS and TGA could fit in the DirectX-flavored re-volt (Shouldnt be dx9 already?)

FYI: THERE'S OPEN SOURCE CLONES OF PS!! FFS

re-volt can support up to 8192x8192 (but still depends in your hardware abilities, see them with -texinfo).

PNG is the best loseless format out there, bmp is M&#036; crap, fat like zip and cabs, so blame them for a fat format.

I'm not sure if the texture count limit is a directx 6 limitation or was done on purpose. That could be fixed. a workaround would be use less textures and more custom mappings for the instances but it will break objects's texture mapping badly and not every computer can do 8192x8192 all the way. it would be very choppy to have such "detail" in a 256x256 texture.

PS: i still prefer 16 bits bitmaps, they're lighter than 32 counterparts and artifacts may vary a lot but they're still present in 32-bits bmps