Our ReVolt Pub

What is it?
Well, there is different theories. Ali, one of the creators of RV-Glue, claims that these are spheres that surrounds some or all meshes, either used for mirroring surfaces or for hiding parts of a level . Jigebren has a similar theory, that they're cubes covering meshes preventing the Re-Volt physics engine from doing specific tests when unnecessary .

Where are they?
They are most commonly used on Stock tracks - almost every single extreme track (excluding unmodified lego tracks ) has only 1 funnyball, covering the whole level. It is currently not possible to see where the funnyballs are hidden, but obviousley the each mesh of the stock tracks are splitted up to fit them.

How do they function?
Based on the latest (and the most popular) theories, you could compare them to Viziboxes, where they instead of hiding the visual, is "hiding" the collisional (Jigebren is quite sure that they aren't connected to ncp's, tho). Basically they make the life easier for the Re-Volt Physics Engine, since these cubes somehow blocks it from testing the parts that they are covering, when unnecessary. Or that is, what I've understood out of the conversations with Jigebren & SkindupTruk.

Here is what Jigebren answered to a couple of questions I e-mail him with relation to Funnyballs:

Jig -> E-mail Reply wrote: > - Re-Volt disables all other parts of your track with the exception of the one you (as in car) is racing in ?
About the physics engine, engine, I think.
About the display part, it's possible that revolt only try to display meshes when they are englobed in a visible boxes.


> - Re-Volt literally do constant "tests" to the meshes with collision in order to determine how objects of different kinds will react as well?
I think so. It's the physics engine part.


> - Re-Volt only loads parts of the ncp file, like if the cubes had references (identities) that matches parts of the *.ncp file ?
Here you're talking about .ncp. But I'm not even sure there is any link made by re-volt between .w and .ncp. So to your question, I would answer No.

Opinions, corrections & questions are very welcome. I am very interested in this subject myself, so all curiosity & information is welcome!

Uhhh... can you show a picture?

Hope this can help, Urne.

Here are some screenshots of Toytanic level (ship1.w) (imported in Blender with a filter of my own).
Notice: Keep in mind that I now think that the green spheres should not be spheres but cubes. But when I wrote this import filter, I though they were spheres (funnyballs from ali's doc).

Theory
In re-volt, a track world is composed of meshes, the meshes are composed of polygons, and the meshes are regrouped in sub-groups, the 'bigcubes'.

Here is the whole 'world' with bigcubes (the green transparent spheres). I have shifted a bigcube and the group of meshes associated whit it.



Here is the group of meshes associated whit the shifted bigcube. The pink lines sperarate the different meshes.



Here I have shifted one mesh from the group. This mesh can be composed of several polygons (2 rectangles here).

I almost agree with jigebren
however, here is my full answer


those funny ball are for collision

it's for theory Distance x Distance collision tests [google sphere-sphere collision]

and as we know, balls are very specific, those funny balls don't really exist, but they exist as "theory" and "pratic collision". these are used for hul (composed of series of spheres) and track collision detection (to Re-Volt source looker: yes, worth to remake a whole new collision detection for this, wasn't it?)

_

Not sure:
The cubes are actually "Binary Space Partitioner" (big mesh) , for saving FPS, as you see, the FPS of Re-Volt is almost constant in stocks, and sometimes it turns up or down, those are because Re-Volt loads cube then make it ready, then once it's requested to draw, it's drawn

i think funnyballs are only to hide visuals since they are used in the W file.

the NCP file has another system of grids tiles. you state the extents of the grid, and how big you want each tile. you then group your NCP meshes into each grid tile.

note the W and NCP are similar in doing this. the W uses funnyballs to group meshes. the NCP uses grid tiles to group NCP meshes.

in both cases you can set one big funnyball / grid tile, and assign all meshes to the one thing.

thats my theory based on looking at the binary and converting it to text and reading what is there in the raw data. making sense of it takes lots of time and patience to confirm in game.

if i ever get time i'd be happy to take a few screenshots in rhino like jiggy has done in blender and show you what i mean.

Thanks for your replies!

SkindupTruk -> Funnyballs hiding visuals wrote: i think funnyballs are only to hide visuals since they are used in the W file.

Were the Viziboxes Mode created for hiding instances only, when made then? Perhaps Viziboxes was a mode created, as an compensation for funnyballs? Afterall the developers seemed to do everything in Habitat. On friday I will try do a test on my old Windows XP, to see if I can create FPS difference by removing all funnyboxes in the Nhood1.W using your tool.

KDL -> Sphere Collision wrote: those funny ball are for collision
it's for theory Distance x Distance collision tests [google sphere-sphere collision]

But since these spheres in your theory is used in long-distance, would the cars ever hit them then or are funnyballs really only used for objects inserted through MAKEITGOOD?

Jigebren -> Pictures wrote: Hope this can help, Urne.

Thank you very much!

I would also appreciate renders from Rhino, if you feel like doing that, SkindupTruk =)

Funnyballs really remains as a mysterium to me. I did a test on Nhood1.w, but I couldn't the FPS staid between 100-160 (V-Sync turned off) both in the version with 1 funnyball and the version with over 200 funnyballs.

I would appreciate if some of you did a test with this world file:
http://urnemanden.com/dload/Temp/Nhood1_notfunny.w

What is the FPS in Nhood1 on your comp? And what is the FPS with the world file above?

Just so you know: The red ENV seems to be a bug, from SkindupTruk's Binary -> Text Converter. I got it before when I converted Market2.

Thank you

I haven't tried 'Nhood1_notfunny.w' in re-volt yet, but I tried to import it in Blender, and the import process failed.
Maybe it's my filter, but it has never failed on any world I tried until now (stock tracks and some user's too, like Jailhouse Rock).
I'm not sure it will change anything to the FPS matter, but maybe the file is a little buggy (for example: the funnyball count not updated?).

Okay, thanks for testing Jig. I added all fodex'es and other data in the funnyball, so it should be working. Perhaps it's because of the size of the funnyball? Did you try load a custom track into Blender with your import filter, yet?

Since I did the code in hand, it could be my fault as well. You can see the world file as text at this link:
http://urnemanden.com/dload/Temp/Nhood1.w.txt

urnemanden @ Apr 17 2010, 10:33 PM wrote:Did you try load a custom track into Blender with your import filter, yet?

Yep, Jailhouse Rock, like I said above. Also Re-Ville, I think, and maybe others I forgot.

Looking at your 'Nhood1.w.txt' file, I'm surprised to see that there is no reference to the multiframe textures list ('UnknownList' in ali's doc), after the funnyballs list.
I think you should at least have the 'UnknownList item_count' set to zero, though I don't know if the SkindupTruk's converter allows it (never tried yet).

And about the ENV bug you reported, it could perhaps be quite the same. There is no reference in your txt file to the EnvList (which contains polygons color), which should be at the end of the file (but maybe no polygons are colored, in that case this list is empty).

jigebren @ Apr 18 2010, 08:15 AM wrote:

urnemanden @ Apr 17 2010, 10:33 PM wrote:Did you try load a custom track into Blender with your import filter, yet?

Yep, Jailhouse Rock, like I said above. Also Re-Ville, I think, and maybe others I forgot.

Looking at your 'Nhood1.w.txt' file, I'm surprised to see that there is no reference to the multiframe textures list ('UnknownList' in ali's doc), after the funnyballs list.
I think you should at least have the 'UnknownList item_count' set to zero, though I don't know if the SkindupTruk's converter allows it (never tried yet).

And about the ENV bug you reported, it could perhaps be quite the same. There is no reference in your txt file to the EnvList (which contains polygons color), which should be at the end of the file (but maybe no polygons are colored, in that case this list is empty).

what is a multiframe textures list and how did you figure it out?!

Re-Volt source:

are called "BIG_CUBE"

location before the Multiframe animation and meshes [world cubes for partitioning the world into cubes to a better render]

on drawworld events: as I see, this keeps the camera more stable. like it's for stabling the camera position

not having them will return false that means, may crash the game (not fully loaded)

SkindupTruk wrote:what is a multiframe textures list and how did you figure it out?! smile.gif

Multiframe (or animated) textures are used for example in the museum level, on one TV screen and to simulate the displacement of the conveyor belt.
As I said in my previous post, it's corresponds to the UnknownList in ali's docs. You can also take a look at this updated page (by darksabre).

To resume, in the .w file, after the FunnyBall list, you have the multiframes items count, then the list of multiframes items.
And after that, there is still the EnvList, until the end of the file is reached.

KDL wrote:are called "BIG_CUBE"

location before the Multiframe animation and meshes [world cubes for partitioning the world into cubes to a better render]

Yep, I said it above:

jigebren wrote:Notice: Keep in mind that I now think that the green spheres should not be spheres but cubes. But when I wrote this import filter, I though they were spheres (funnyballs from ali's doc).

Theory
In re-volt, a track world is composed of meshes, the meshes are composed of polygons, and the meshes are regrouped in sub-groups, the 'bigcubes'.

Funny ball are in fact BigCubes.

KDL wrote:as I see, this keeps the camera more stable. like it's for stabling the camera position

I don't think the part of code you quote is designed for 'stabilising' the camera. It tests if the BigCube is outside the view 'frustum', and in that case, all that is inside this big cube will be skipped by the rendering engine.

ah yea, didn't paste the full code

however, yea, "initialize the frustum" (is more professional than making the camera stable and fix it, because not everybody here have a 3D knowledge )

I've started to work on a tool to 'play' with world file. I can now read .w file, I wrote a procedure that can create bigCubes (aka funnyballs) (only when meshes are properly cutted out, like in the stock tracks), and I can write the .w file back.

To see the influence of bigCubes (funnyballs), I have modified the museum2 track (the one used with the 'gamegauge' command line option) so that is only have 1 global bigCube, like in the majority of (in all?) custom tracks (Urnemanden has done something similar previously with Nhood1).

Here are some extracts of the FPS.txt file created with gamegauge option. The first line is the average FPS.

With original museum2:

157.89 Re-Volt v1.00
121 Min
189 Max

With modified museum2 (only 1 bigcube):

156.22 Re-Volt v1.00
114 Min
195 Max

For completeness, I tried with no world at all (only instances and collision, etc. are loaded). In that case we'll reach the maximum FPS possible (at least, as far as the .w file is concerned in slowing down the FPS):

217.93 Re-Volt v1.00
174 Min
291 Max

So it seems that I reach the same conclusion than Urne, in that the bigCubes have not a incredible influence on FPS (on modern system at least). But bigCubes seem to help keeping a more regular/constant FPS.
Also, we have to keep in mind that stock track are properly cuted out in several little meshes (cubes) and it could also help the FPS, even with no bigCubes (that what I discussed about in the 'Improve Jailhouse Rock Fps Topic').
If I could manage to write a procedure to join all meshes in on single mesh, maybe I could see this influence.

I tried to mesh-divide Forgotten City (14000 tris), but as I can't import world files without having to make them go through Zmodeler and then into Gmax, the size will change. It would be cool dividing up a track like JungleVolt (54000 tris) or Bone Island (108000 tris), since you definitely will feel a difference in the FPS, if the results you came with is true. Sadly, I don't got 3ds max anymore ( )

I've implemented a procedure to merge all cubes (meshes) in a single one. It's done it a quite simple way, I'm not trying to merge similar vertices, for example.
I applied it to the muse2 track, to see if it would change the framerate, and results are quite surprising.
I ran re-volt with command option 'gamegauge' in 800x600 fullscreen. Here are FPS results taken from the fps.txt file genreated by 'gamegauge' mode.

unmodified muse2:

179.33 Re-Volt v1.00
152 Min
217 Max

muse2 with only 1 bigcube (funnyball):

178.74 Re-Volt v1.00
150 Min
219 Max

muse2 with all cubes (meshes) merged in one single cube (obviously there is also only 1 bigcubes):

211.05 Re-Volt v1.00
163 Min
280 Max

So it seems that funnyballs have no real influence on FPS.
And paradoxically, having the world divided in several meshes seems to lower the FPS, while it was designed originally to increase it.

Maybe I should also try on a custom track like Jailhouse.

For now, my idea about it is that, as the process of testing cubes/bigcubes is done by the cpu, it could be more expensive in term of calculations than letting everything to be displayed, as display is done by the graphics cards with its own gpu (and this doesn't eat cpu calculation power).

that's odd, but thanks for testing

so, what is it for then? not BSP? [BSP: Binary Space Partitioning]

KDL @ Jun 7 2010, 10:28 AM wrote:so, what is it for then?

It is designed to improve the FPS.
But what was optimal when re-volt was released is not necessarily optimal on today's hardware. Because hardware, and mainly graphics cards, have evolved quite a lot since 1999.
- - - - -

I have now written the hardest part of my tool: the procedure to cut out the world in several meshes. Quite surprisingly, it seems to work now (to be honest, after having suffered from some nasty bugs, and in front of the complexity of the task, I was not sure to carry on and finish it).

I've tried with 'Jailhouse Rock' track. And at first sight, result seems interesting. With original Jailhouse, I have an average FPS of roughly 45. With the cutted-out and 'big-boxed' (funnyballised) Jailhouse, I get an FPS of ~145.
And it also does what I was secretly hoping : it fixes (or at least, it lowers) the bug of windows meshes that disappeared under some particular angles of view...

So I think there could be a real benefit of having track worlds with proper cubes and bic_cubes, even if, depending of the track complexity and of the hardware used, it seems sometime to lower the FPS (see my previous test). And maybe the most complex tracks could be the one to benefit the most.

Nice! When you release it, I'll gladly test it out on Floating World to see if it makes the bug dissappear there as well.

urnemanden @ Jun 8 2010, 08:51 AM wrote:Nice! When you release it, I'll gladly test it out on Floating World to see if it makes the bug dissappear there as well.

I tried with Floating World too.
I can't see the 'mill wheel' disappearing anymore, at least in my last try. But the situation in which it disappear wasn't so clear, so I can't tell if there is really any changes.

And I now think there is another issue with this track, because there were still drops in the FPS. After a quick investigation, I now think that it came from the bubble model (modelling a sphere is quite 'polies consuming'). Like with the Jailhouse Rock track, it seems that there could be too much semi-tranparent polies.
Unfortunately, I can import model in blender, but not export them, so I can't do anything about it.

Could you try send me the *.w file? What is the maximum polycount for semi-transparent polygons?

urnemanden @ Jun 22 2010, 10:17 PM wrote:Could you try send me the *.w file?

Here it is (right clic -> save as):
floating world - BigCubed world file.7z

What is the maximum polycount for semi-transparent polygons?

From memory: 1400.

EDIT:
I still had one 'mill wheel' disappearing with the cutted out world (I think it's the second one from the starting point), so I tried other things. In fact, it seems to be an issue with a Visibox (camera number 2) that make the wheel disappear. Moving this visibox or simply deleting the .vis file fix the issue.
I didn't go further, because I'm not very comfortable with Visiboxes editing, but there is probably a cube box associated with the camera 2 box that has to be moved.

Testing the bigcubed world still made the wheel disappear as you also stated, I never thought that the *.vis really did affect objects as well though. I better try find out which cube needs some adjustment.