Our ReVolt Pub

Here are some ideas that could help increasing the FPS of a track, and maybe prevent some bug, like the 'Objects are hiding' one below (I say 'could' because I can't ensure it will change anything, I have not tested yet).
It is following some posts in the WolfR4 topic.

jigebren @ Apr 11 2010, 07:35 PM wrote:Objects are hiding
Here is the screenshot of this bug in Jailhouse Rock. The windowpanes have disappeared.



It appears at least when you're at this place, in this angle of vision, and as backward as possible before falling in water.

[quote="human @ Apr 19 2010, 09:59 PM in Topic: "Wolfr4 Tool""]

@human
I don't think you feel like working again on Jailhouse Rock (I want to mention that the more I look at this track, the more I see the wonderfull work you've done), but if you want and have a little time, I could give you some ideas about operations you could try on your world meshes to maybe fix (or lessen) the dissapearing objects 'bug', and maybe increase a bit the FPS.

yes, jig, i am interested in anything that can make tracks better, like increasing fps and stuff. please tell me more about your ideas.[/quote]
I don't speak about FunnyBalls/BigCubes here because I think there is no way to edit them easily.

About meshes in world file:
@human
In jaihouse, you have used the severals meshes depending of what purpose they'll have (eg: ground, a dirt layer, walls, lamps, etc.)
It can make sense when working in tour 3d editor, but in re-volt I believe it has no sense anymore.
In revolt, I think meshes have to be geometrically distributed.

A mesh in re-volt has an englobing box, and if I'm not mistaken, this box is first tested by the rendering engine, and if it is not visible, then the whole content of the mesh can be skipped.
Thus if the world consist of several little meshes, it can ease the rendering job a lot (all polies in the skipped meshes won't be tested), while if you have one single big mesh, all polies have to be tested for display.
Moreover revolt will work with a smaller list of polies, and I have hope it could lessen the 'Objects are hiding' bug.

So what I think you can do before exporting a world for re-volt:
First, if you have worked with several meshes, join them all in one single mesh.
Then imagine a sort of 3D virtual grid (using a reasonable step), and cut out the big mesh in several meshes, following approximately the virtual grid.

If this explaination is not clear, take a look a the toytanic example in the Funnyballs topic. Of course, things are a bit different: in the toytanic example, there is funnyballs/bigcubes and meshes subdivision, while here we are only using the meshes subdivision.

I make the main track mesh witch is just one
big mesh. It is most of the track. Then put that big mesh
in the world file. I then add the trees plants what ever.
These do not get glued in the world file. I think it is better
to have half the prms in the world file and half in the ncp
file. That way they share the load. Look at stock tracks
all the prm files are not stuck in the world file.
This is how to help fps. I think?

So the way I have exported meshes for the last few years was actually correct? I always break up my mesh into small chunks to aid the FPS but Human ran a few tests and said that his FPS were lower while doing so.
I will always stick with the idea that smaller parts to a mesh will aid the rendering because like I said before that on a real slow PC (Like mine was while making my tracks) this proved realy productive as it speeds up the export tool aswell as the FPS.
I take my mesh breakup one step further with great results and that is to break all polies in each object in max.
To sum up my mesh will be busted up into lots of grouped objects like wall 1,2 blahh blahh and then that object will be busted up into single polies. This works on all of my PCs for improved FPS.

@rickyd
You have a bit misunderstood me on a point, I think: I'm not talking about instances or objects at all, nor about the 'gluing' operation...
The idea here is just to optimize the World mesh (or more exactly the world meshes) to minimize the load on the re-volt engine when racing. And I think it can be achieved by doing a proper subdivision of the World mesh (the .w file only).

@Skitch2

  So the way I have exported meshes for the last few years was actually correct?

It's very possible. Though I'm not sure I have propely understood all the subtlety of your explaination, for example "that is to break all polies in each object in max", but I could try to take a look at one of your tracks to see what you really mean.


I don't know it human will have the time the try to edit Jailhouse, or if he will keep the idea only for a future track. I would be quite interested to the result on Jailhouse as the 'Objects are hiding' bug is clearly reproducible and the PFS isn't that great (on my computer, of course, which isn't that powerfull).

So what your saying is you detach all the polygons?
So there are 1000s of polygons you glue to the world file?
Is this right? Do I get it or not?

Sorry, rickyd, I'm not following you... Who said to detach all the polygons?
I don't know how you use to work, because here you're talking about gluing, but if you make your world fully in your 3d editor, I don't think you need to glue anything, do you?

I know it's not easy to explain without images, but I have no time for screenshots, etc.

In a simple revolt World file (.w file), you can have several meshes, right? So you can choose to have the whole world in one single mesh, or you can cut out the world in several meshes, and that's what I think have to do be done.
Of course, each of these meshes is itself composed of several polygons.

The revolt engine tests if it has to display the mesh before testing if it has to display all the included polygons (thus it go faster when the mesh can be skipped).

Never mind.
Seems re-volt is dead anyway.

no no no! re-volt is never dead! long live re-volt!

We all know that re-volt is dead, and a long time ago. So?
Well, maybe we're necrophagous gamers, because it seems we can still feed on it.
Anyhow, it's not really the point here...

Anything that can help improving FPS interests me, so I'll try this method out on my next track(s).

Well the best way that I have found is this...
build your track,
Break the track up into "Objects",
When I say Objects I mean like "Road1, Wall 1, Wall2, Tree1....and so on.
Then pick an object and use the "explode tool in Max to bust the object into it's singular polies. In my way of thinking it allows RV to munch away at the polies lots faster by way of utilizing the far clip better. Imagine the Farclip and fog setup steadily chomping it's way threw your track with no effort and the it reaching a big long poly that has to stay rendered until it's fully covered by the far clip? yea this put undue strain on the rendering engine. Also you can test this with the ASE2w tool. Try converting a new ase file that is one whole object. I can tell you that it takes bloody ages on a fair PC. Now break the mesh how I say to and the ASE2w tool will bipp threw the converting stage in a flash... Bish Bosh all done....

@Skitch2
Followinf your PM, I have downloaded and tried Hull Breach 3 (really impressive track, I have to say).

In this track, meshes seem to be distributed quite in a similar way that what I tried to explain (like you said above).
Except maybe ground meshes, which are somewhat too large, though.

Being finicky, I would say that there is no real need to separate ground from walls, etc, in several meshes.
It could be better to cut out some "cubes" from the world.
One mesh would then be composed of everything that is inside this (virtual) cube: walls, ground and everything else.

I like that idea Jig! I will deffo do that for my next one and see what its like.
I do tend to keep the grouds as one mesh but i break all the verts. This seemed to help with FPS and conversion through the ASE2W tool.

hey guys, apologies for being away for a bit.

my thoughts on this subject:

i have never made one big mesh for a revolt track. this was due to several things: in the beginning, i just havent tried it, later when i did want to try it i had hardware related problems with that, because it takes a lot of pc power to attach poligons to each other in a mass, so whenever the poli count reached a certain level, my pc freezed when trying to attach objects with high number of polis together. this is what has happened to jailhouse as well, as a result the final version of jailhouse mesh contains not many but still a few big meshes.

now i did this, because when i tried mike's method of exploding the mesh to individual poligons for me on my pc didnt show the results i expected based on mike's experiences. i cant remember if i detached all the polis or i was forced to leave objects/meshes in one pieces because the above mentioned poligon attach/detach operation that tends to be too power hungry on my pc. one thing is sure: the whole mesh is neither one object (i use mesh and object referring to the same thing here, object, mesh, model, etc) nor one mesh chopped up into many smaller individual meshes following an evenly distributed grid based system, they are random - bigger and smaller- meshes unevenly formed in terms of shape, poli count and poli size.

so, if they were meshes (objects/models) built from similar sized polis put next to each other nicely, that would be the arrangement that jiggie is suggesting. on the current jailhouse mesh, its neither that, nor what mike is saying about a completely exploded mesh. at least this is how i remember to the last stages of building the mesh in 3dsmax.

i hope you understand me guys, i know my english is not that good. some thoughts in points because time is flying:

- how do chopped up mesh and viziboxes work together. do mesh pieces match viziboxes at all on original tracks? according your theory jig, does engine consider mesh pieces first and then viziboxes when it comes to rendering?

- some max related thoughts, sorry jig, you may not understand these fully, but mike does:

-editable mesh or editable poli?
-detach (poli) or explode (mesh) maybe not the same for revolt or not the same for asetools?
-does size matter? one big poli is still only one poli after all, is it more difficult to render a huge poli than a tiny one?
-converting have never taken considerable amount of time to me. for example jailhouse (cant remember again, maybe 30k polis) takes 3 minutes to convert with asetools. and i dont think i experienced a difference with the mesh exploded to polis or one big mesh.

this is a bit messy post, i cant think in english, just a few thoughts added to this topic.

Glad to see you back, Human.

so, if they were meshes (objects/models) built from similar sized polis put next to each other nicely, that would be the arrangement that jiggie is suggesting

It's quite that, but it's more "world with similar sized meshes put next to each other nicely". I don't think the size of polies matters (of course, except the fact that bigger polies often means less vertices, which is better).

- how do chopped up mesh and viziboxes work together. do mesh pieces match viziboxes at all on original tracks? according your theory jig, does engine consider mesh pieces first and then viziboxes when it comes to rendering?

First, I have a doubt: do you really talk about visiboxes (added in the corresponding MAKEITGOOD mode) or do you talk about funnyballs/bigcubes, which are part of the world file?
- If you're talking about visiboxes, I'm not enough aware of this subject to be sure I won't be mistaken, but for now, I think there are only used as supplementary tweaking to improve a little more the world rendering speed, by allowing to hide some areas that we are sure we don't want to display when the camera is at certain positions.
- In case you're talking about funnyball/bigcube, you could take a look at the FunnyBalls topic. I said above in this topic that I won't talk about bigcubes because there is currently no way to edit them AFAIK. I was thinking about trying to make a tool to create these bigcubes, but honestly, I don't think I'll ever do it.

Just one word about the explode mesh/poly stuff you talked about, I'm not sure what this function does, but in the case it dissociates vertices that are shared between polies, then it is not a good idea to use such a function, because I'm quite sure sharing vertices would lessen the load on the 3d engine.

hi jig,
i was talking about visiboxes, the same question applies to funnyballs too, but i know nothing about them, so i didnt mention them.
- are funnyballs generated automatically by revolt?
- if the world is built up from similar sized meshes, how can the engine decide without visiboxes what to display? if there is a need for visiboxes, why does the engine still think about the whole world? do you think the engine works this way:

1. considers the WHOLE world file regardless to the visiboxes
2. ignores the meshes that it thinks it doesnt have to display (funnyballs?)
3. takes the visiboxes into account and ignores the poligons that are not visible from that box

if visiboxes ALONE dont do the job, then there is the question:

- how can the engine decide which mesh to ignore? i dont think there is a way to tell it without the human intelligence, as i may want something to be displayed even if its not naturally visible from a certain viewpoint, and may want to hide something that is naturally visible from a certain point in space on a track. this is what visiboxes do.

I probably didn't understand Jigebren correct but here is my guess: The viziboxes tells Re-Volt when to render/hide certain polygons, while the mesh-dividing simply helps Re-Volt loading/rendering them constantly or cordinate when the objects should be shown. Funnyballs is then for simplifying the "physics" in distance. Funnyballs is not generated by Re-Volt, but is written into the world file and surrounding the divided meshes. If you convert your track using ase2w, the converter creates 1 funnyball surrounding all meshes.

- are funnyballs generated automatically by revolt?

No. Funnyballs (bigcubes) are part of the world file. They would need a dedicated tool to be created.
Currently , like Urne said, the usual way of proceeding is to have one single funnyball surrounding all meshes, but it's just to prevent re-volt from crashing, it has no other usefulness.

- if the world is built up from similar sized meshes, how can the engine decide without visiboxes what to display?

Each mesh has its own surrounding box. The engine first test if the surrounding box is enclosed in the viewing frustum. That way, it can very quickly decide to skip a mesh, without having to test for the whole list of polies insides the mesh. It can speed up things a lot.
Of course, when a mesh has actually to be displayed, it doesn't speed up anything.
For completeness, I would add the when bigcubes is only partially inside the view frustum, then it get a special attribute so that the engine knows that only some polies of the mesh have to be displayed, not the whole mesh (it then does some supplementary test on each poly, I think).

do you think the engine works this way:

1. considers the WHOLE world file regardless to the visiboxes
2. ignores the meshes that it thinks it doesnt have to display (funnyballs?)
3. takes the visiboxes into account and ignores the poligons that are not visible from that box

Yep, it's quite that. With one little subtlety (I think you already means it but I'm not sure). On the contrary to funnyballs, visiboxes are not used to know what to display, but to know what not to display. I mean that the way visiboxes work is: when the (player's) camera is inside a camera visibox with a certain ID, all cubes visiboxes with the same ID are automatically hidden. But I don't know exactly in which way visiboxes are linked to world meshes.

Also, keep in mind that I'm not thoroughly sure of all that I say here, mainly about visiboxes, I could be mistaken.

- how can the engine decide which mesh to ignore?

The answer is above, with the view frustum, etc.

i may want something to be displayed even if its not naturally visible from a certain viewpoint

I'm not really following the idea. If you still think that after the explaination above, don't hesitate to develop.

and may want to hide something that is naturally visible from a certain point in space on a track. this is what visiboxes do.

Right, this is what visiboxes do.

urnemanden wrote:the mesh-dividing simply helps Re-Volt loading/rendering them constantly or cordinate when the objects should be shown.

IMO, to resume thing a bit, the only goal of the mesh-dividing is to subtitute all polies from a mesh with a simple surrounding cube during preliminary calculations.

thanks jig, i think i kind of understand
so if we had a tool like 'ase2funnyballs' that would increase fps dramatically? you know, ase2w, ase2prm, ase2funnyball

human @ May 25 2010, 02:49 PM wrote:so if we had a tool like 'ase2funnyballs' that would increase fps dramatically?

Maybe not 'dramatically', but it could possibly help to reach a better FPS, and also, by reducing the number of polies displayed in each frame, it could also help to prevent the disappearing windows bug in jailhouse. But it's not possible to say how noticeable the improvement would be... I don't think we can expect someting incredible.
Also, the tool doesn't have to work with ase file, it could and had better work directly with world file (.w).

yes, that is how i meant, if ase2w could convert it to a word file. i know there are no funnyball files, so an 'ase2funnyball' would be useless.

Jig wrote:Also, the tool doesn't have to work with ase file, it could and had better work directly with world file (.w).

In that case it would be cool if that tool could help the track maker creating multi-frame as well.

Does the mesh parts have any specific size, each?

I talked recently in the FunnyBalls topic about the tool I wrote to cut ou the world file in proper Cubes and BigCubes, like the stock tracks. I have applied this tool to Jailhouse rock track, using quite similar sizes for the Cubes and BigCubes than those used in stock tracks.

So, with the 'BigCubed' world file, I can get a more than doubled FPS on my system, which is already appreciable (from ~45 to ~145 at the starting grid position, for example).

And it seems to lower the "Objects are hiding" bug I reported above. I say 'lower' because now, the windowpanes don't disappear anymore, but I can still see a modification of the opacity, probably linked to the disappearance of one of the superimposed meshes Human used when creating his track.

And last, it also seems that it quickens quite a lot the jailhouse world file loading and it's nice, because it was quite slow before on my system.

You can download the modified world file (.w) here:
Jailhouse World with BigCubes.7z
I'm curious to see if anybody can notice the same FPS improvement. Also, thanks to report if you notice issues introduced with this file, to see if my tool is working nicely.
For example, there is some artifacts on the water surface, but they were already here with the original world file (so please check the original world file before reporting).

- - - - -

@Human
There is a very big polygon used for the ground in this world. Would it be a hard work for you to subdivise it a bit and export the world file again?
Because having a big poly implies that the englobing BigCube has to be at least as big, and we could probably lose the benefit of using BigCubes...

With original *.w
FPS: 90 - 145

With cube-divided *.w
FPS: 105 - 150

I currently still see the objects disappear in both world files, tho.


I hope that dividing the individual meshes up into more, will help on that.

So when i release my first Zmod track, i might look into these funnyball thingies.

@Urne
Well, I think it's a wrong example, Urne. If I'm not mistaken, what you're showing is the normal effect of Viziboxes set on purpose by Human to hide areas that don't have to be seen in normal circumstances (check in Vizibox Edit mode). And here you are in a position a normal car can't reach.
I made 2 new screenshot for what the 'disappearing object bug' really is. If you place your car like in the first screenshot, you'll see the windowpanes. Just move back (the car) a little, the windowpanes will disappear (second screenshot).
--->

In Cube-divided world, windowpanes won't disappear anymore. But we can still notice a little alteration of the transparency, though.


Also, I haven't specified it, but my FPS test were done in fullscreen mode. It'd be better to collect FPS in fullscreen mode only (I'm not sure windowed FPS is really consistent). Urne, can you specify which mode you've used?
And have you noticed the level loading speedup? (on my system, it's pretty obvious).

I hope that dividing the individual meshes up into more, will help on that.

In fact, I'm more inclined to think that dividing more would only entail unnecessary calculations:
You know, testing Cubes and BigCubes is a supplementary work, and it's only profitable in case the content of the tested Cube can be skipped (but in some case it can be very profitable, that's the trick). Adding too much Cubes will increase the number of tests to perform and lower the benefit when the content can be skipped.

Jig wrote:Well, I think it's a wrong example, Urne [...]

I cannot confirm that it's because of the viziboxes as you say, entering vizibox mode makes my computer lagg too much, so I can't check it. I can say that it can be seen from the car, tho.

I can confirm that the new world file fixes the transperancy bug you've taken pictures of as well, jig.

Jig wrote:[...]Urne, can you specify which mode you've used?
And have you noticed the level loading speedup?

1. I used fullscreen with V-Sync disabled.
2. Yep, your world file is a true Ferrari

About dividing meshes into pices, could you possibly show me through images, a case where it is a profitable trick?

urnemanden @ Jun 11 2010, 05:11 PM wrote: entering vizibox mode makes my computer lagg too much

That's also true for me with the original world file. But have you tried with the cube-divided one? On my system it changes a lot.

I can say that it can be seen from the car, tho.

One point for you.

About dividing meshes into pices, could you possibly show me through images, a case where it is a profitable trick?

I don't really see what you want me to show you.
What are you alluding to with 'dividing meshes into pieces'?
And just to be sure we'll both use the proper terms, here they are:

theory wrote:In re-volt, a world is composed of Cubes (meshes in 3D editor), the Cubes are composed of polygons (can be triangles or rectangles), and the Cubes are regrouped in sub-groups, the BigCubes (aka FunnyBalls).

Jig wrote:But have you tried with the cube-divided one? On my system it changes a lot.

That's true, it does change something here as well. I also tried running Jailhouse without viziboxes, and you're right - it seems to be the viziboxes fault.

I just wanted to know when it was a good idea to divide your mesh into several meshes. For example in the same way as I explain when to place a vizibox on my very nice made-by-hand picture

I tried to draw quickly some diagrams... hem, I think I'll try with words only, finally...

You (quite) never really have to divide a mesh into several meshes. The first I do with my tool is merging all meshes in one single mesh. Then I'll cut out this mesh in several Cubes according to a grid setting.
Here we have to keep in mind that I will never cut out a polygon in several polies. So it's good not to have too big polies, because the Bounding Box of the Cube (the bounding box is what will be tested first by re-volt engine) has to be at least as big as the biggest poly in the mesh. And if the bounding box is too big, it means it will be too often visible, and it's not the goal.
That's why I asked to Human if he can break one of his poly into several ones, because the poly in question is quite as big as the whole track...

The usual size of a Cube's side in re-volt tracks seems to be close to 1000 (in re-volt unit). BigCubes size seems to be roughly 2500. Take a look at the screenshot of Ship2 in the Funnybal topic, and you'll see usual size of polies, compared to Cube and BigCubes.

I hope my explaination is understandable enough...

Thank you Jig, your explanation helped me a lot. That lead me to some questions.

Jig wrote:You (quite) never really have to divide a mesh into several meshes. The first I do with my tool is merging all meshes in one single mesh. Then I'll cut out this mesh in several Cubes according to a grid setting.

Does these cubes "exist" or are they guidelines for where to cut the mesh into several meshes?

Jig wrote:Here we have to keep in mind that I will never cut out a polygon in several polies. So it's good not to have too big polies, because the Bounding Box of the Cube (the bounding box is what will be tested first by re-volt engine) has to be at least as big as the biggest poly in the mesh. And if the bounding box is too big, it means it will be too often visible, and it's not the goal.

So, this is a question of whether lowpolyness or the goal of having 1000 unit cubes in order to save FPS that way should be of highest priority?

Jig wrote:In fact, I'm more inclined to think that dividing more would only entail unnecessary calculations:
You know, testing Cubes and BigCubes is a supplementary work, and it's only profitable in case the content of the tested Cube can be skipped (but in some case it can be very profitable, that's the trick). Adding to much Cubes will increase the number of tests to perform and lower the benefit when the content can be skipped.

The part above was what confused me a bit. Your tool works per automatique and does therefore not know when to cut, unless it's quite advanced. That was why I asked in which case cutting smaller/bigger cubes would be profitable. By saying that, do you then also take into consideration that each cube seems to be 1000 RVunit? And how close is close?

Jig wrote:The usual size of a Cube's side in re-volt tracks seems to be close to 1000 (in re-volt unit). BigCubes size seems to be roughly 2500. Take a look at the screenshot of Ship2 in the Funnybal topic, and you'll see usual size of polies, compared to Cube and BigCubes.

Is there any tracks that seems to have larger or smaller cubes, compared to the usual close-to-1000 unit cubes? And in that case, could you come with an example and perhaps a guess on why this track happens to have larger or smaller cubes than the rest of the tracks?

urnemanden @ Jun 11 2010, 08:07 PM wrote:

Jig wrote:You (quite) never really have to divide a mesh into several meshes. The first I do with my tool is merging all meshes in one single mesh. Then I'll cut out this mesh in several Cubes according to a grid setting.

Does these cubes "exist" or are they guidelines for where to cut the mesh into several meshes?

The Cubes are first only guidelines. At the end we can consider that they exist, but in the form of a bounding box only, they are not meshes. The process for my tool is roughly:
- I set a virtual 3D grid, which depends on the Cube's side size. This grid is the guideline.
- For every polies of the world, I check to which virtual cube the center of the poly belongs. So for each Cubes I have a list of included polies.
- Then the size of each cube is tweaked to fully englobe all the polies in its own list. Here, the cube size can increase or decrease, depending of the included polies. At this point, you can understand why, when if a big poly exists in the world, then its 'parent' Cubes will become as big.
- When I know all Cubes, I set another virtual grid for BigCubes.
- For each Cubes, I check to which BigCubes it belongs. When it's done, I adjust each BigCubes size and center position depending of the all Cubes it contains.

So at the end, Cubes and BigCubes are data in the World file, in form of bounding boxes and/or englobing spheres.

So, this is a question of whether lowpolyness or the goal of having 1000 unit cubes in order to save FPS that way should be of highest priority?

Well, it not easy to be categorical. I think you have to create your track with lowpolyness in mind. But, at least as far as Cubes/BigCubes are concerned, I would recommend against using, for example, one single big rectangle that would cover all the track even if you know that you can do it. In that case it's probably better to cut it out in several rectangles (moreover, the use of textures will be more effficient on more little rectangles).

Jig wrote:In fact, I'm more inclined to think that dividing more would only entail unnecessary calculations:
You know, testing Cubes and BigCubes is a supplementary work, and it's only profitable in case the content of the tested Cube can be skipped (but in some case it can be very profitable, that's the trick). Adding to much Cubes will increase the number of tests to perform and lower the benefit when the content can be skipped.

The part above was what confused me a bit. Your tool works per automatique and does therefore not know when to cut, unless it's quite advanced. That was why I asked in which case cutting smaller/bigger cubes would be profitable. By saying that, do you then also take into consideration that each cube seems to be 1000 RVunit? And how close is close?

Just to clarify, the 'unnecessary calculations' I talked about are for the re-volt engine, when racing.
And, well, it's not really easy to explain better without writting a whole book... I just meant that if you have too much Cubes, you'll spend so much time testing the Cubes themselves that it will become as slow as testing the polies directly. You see the idea?

Is there any tracks that seems to have larger or smaller cubes, compared to the usual close-to-1000 unit cubes? And in that case, could you come with an example and perhaps a guess on why this track happens to have larger or smaller cubes than the rest of the tracks?

I don't know, I haven't look at all tracks. But anyway, the 1000 unit value (of which I'm not even really sure) has to be taken as a general precept, it's not an absolute rule. Just respect the simple rule to have quite balanced polies size, neither too big nor too detailled, and I think it'll be ok.
Maybe with practice we could determine more optimal values, but I doubt they will make such a big difference, and moreover it could probably be quite harware/OS/driver dependant.

Thank you for the information, I only got a few questions left:

Jig wrote:[...]the 1000 unit value (of which I'm not even really sure) has to be taken as a general precept, it's not an absolute rule. Just respect the simple rule to have quite balanced polies size, neither too big nor too detailled, and I think it'll be ok.
Maybe with practice we could determine more optimal values, but I doubt they will make such a big difference, and moreover it could probably be quite harware/OS/driver dependant.

Do you mean balanced compared to each other or balanced compared to how large or small the track is to the R/C Cars?

About the thing that takes a year to write, I think I got it somehow. Wouldn't it take a lot of time to find out/calculate when the engine will skip the cube and when it therefore would be an advantage to create a larger or smaller cube, compared to the rest? I think that's why doing it per automatique through a tool lik yours would be less braincell-killing.

Oh, and can you confirm that when I divide my mesh up into several in a 3D modeller and then export it through ASETools, each mesh will have it's own cube?

Do you mean balanced compared to each other or balanced compared to how large or small the track is to the R/C Cars?

I mean both. Well, in itself, comparing the size of the track polies and the size of the car has no real scientific value. So 'balanced compared to each other' could be enough. But keep in mind what I said above: it's ideas and general principles.
The only thing sure is that using big polies will create big Cubes and big BigCubes (with my tool). THAT is sure. The fact that it will lead to worse performance and everything else are suppositions.

Wouldn't it take a lot of time to find out/calculate when the engine will skip the cube and when it therefore would be an advantage to create a larger or smaller cube, compared to the rest?

I think it's a matter of statistic, and a full theorical study of the issue would be necessary to find out the proper anwser. It would surely be quite complex IMO.
Experimentation is probably a simpler way to proceed in that case, but nothing can guarantee that the result will be the same for all OS/hardware, etc...

Oh, and can you confirm that when I divide my mesh up into several in a 3D modeller and then export it through ASETools, each mesh will have it's own cube?

I can't affirm it, because I have never used ASETools. But I'm quite sure it will. You'll still lack BicCubes though (there will be only one BigCube for the whole track). But maybe you can already reach pretty descent result with that method (which is what I tried to explain at the beginning of this post).

hey guys,
sorry for not being active recently, but i really am busy currently with other things.
i will have a look on the jailhouse world file. first i need to find it on my pc, but the search tool will help hopefully
now, i can try to make one big mesh and devide it into many small meshes according to a certain pattern/web/grid. how big should these be? like, how many jail cells should they contain? 1, 2, 4, more?


this following section is to be read only if the reader is very fit and relaxed its 3ds max related and i dont know what that is :

my only worry is that according to my experiences, if there are two neighboring meshes (both with a certain number of polis) and they are not joint with vertexes welded, there is a funny/weird phenomenon along their mutual edges, its kind of flickering as i move with the car. what i mean: imagine that two meshes meet at vertical the center line on the wall between two doors. ok, now when im approaching the place, the line on which these edges meet is flickering, not sure what it is and cant really describe it better with my english. mike (skitch) said he doesnt experience it, i dont know. that big poligon you mentioned jig, is inserted for simply this reason: to stop this flicker thingie by covering the track from underside from the light blue default environment, so there is no light coming through these edges (they still flicker, but we cant see it) we could simply remove that huge poligon, because no other purpose, its just blocking light. ill see what happens.

is that ok, if i take the plan view and put a grid on the track and slice it up like a cake following the grid regardless to the different levels (upstairs, downstairs)? or should i cut out cube shape poligon-groups per level, a row of cubes for each floor?

Hi Human,
Sorry, I forgot to tell you to look also at the Funnyballs Topic, as I talk more about my new tool there.

To (try to) resume:
Now, contrarily to what I said at the beginning of this topic, you don't have anymore to separate polygons in several mesh yourself (providing my tool could be eventually useable of course)... I have wrote a procedure that should be able to do that automatically.
The only thing that my tool can't do is dividing polygons.
But it is able to merge all meshes in one mesh, and it is able to parcel out polygons into several meshes according to a virtual grid.
It is now even able to join vertices that look similar (close positions, and similar normals, but it's quite slow).
And when it's done, it can also create BigCubes (FunnyBall).

So you don't have to modify anything in your world file except cutting out (or removing) the big polygon, because I can't cut this poly out...
(Well, ideally , you should also have to remove some tranparent polies if possible, because it's looking that there is too much of them, for example the water surface is flickering weirdly...)


And I think I see what you talking about in the second part. Not sure I've actually understood all that you mean, though. What I see, I would have not really call it 'flickering', for me, it looks like the polygons are not perfectly joined, and that there is a gap between them, that sometime make some blue pixels appear. It could be a very common 3D issue, I think.
I can see that sometime on Re-Ville track, for example. But once again, I don't know if that's really what you're taking about...

To try to deepen the blue pixel artifact subject, I have imported your track in Blender to look at some parts where I remember having already seen that artifact (eg. in the water room).
Hem, I'm sorry, I don't want to look pretentious, giving you some modeling lessons that you're perhaps already aware of, but, well, AFAIK the way you've modeled some polygons is forbiden in 3D. I have pointed out with a red arrow the incriminated edges junctions in the screenshots below.




It's not very easy to explain, but the principle is quite easy and mostly obvious. You can't have several edges joining in the middle of (or alongside) another edge without also cutting this last edge at the intersection point.
Otherwise, there is a hole between all those edges. You can't see it, but it is here.
Luckily for the exemple, here it can clearly be seen on the first screenshot (where the red arrow is, we can see the skymap through the hole), because the water effect is distorting the polygons, thus enlarging the hole.

The issue should be fixed by cutting the edge at the point indicated by the arrow, and merging the new resulting vertice with the one already present (the old intersection point). But now that the track is textured, it may be hard to do it without messing with the UV texture coordinates (depending on 3ds max tools potentiality, which I'm not aware of).

Cutting an extra polygon on an already UVW Unwrapped is not a problem. The only thing that might be a problem, is if you don't hit the vertex/white line exactly. In that case 3ds max/Gmax will create another very small polygon to join your cut and the vertex.

urnemanden @ Jun 15 2010, 09:30 AM wrote:Cutting an extra polygon on an already UVW Unwrapped is not a problem.

I agree with that. But for me, the real difficulty would be to indicate that you want to break the edge precisely at the intersection point of other edges. For example, I'm not sure I would find a way to do it properly in Blender. But I haven't tried yet, there should probably be a trick.

In that case 3ds max/Gmax will create another very small polygon to join your cut and the vertex.

In that case, you can probably use a "Join similar vertices" kind of tool to remove the small polies when your cutting job is done.

yes jig, the blue pixels along the edges are exactly what i meant.

yes, insert a vertex and snap/weld it to the existing is not a problem, but the track is so big and complex that it takes quite a lot of time, thats why its not perfect vertex-wise.

im sorry for my absence, i just cant spend more time with revolt nowadays. ill look up the file and remove that poligon and ill check the water-surface, its easy to remove semitransparent polis from it, but i might look too simple without it, maybe im just too graphic centered.

human @ Jun 18 2010, 01:10 AM wrote:but the track is so big and complex that it takes quite a lot of time

That's very true.

ill look up the file and remove that poligon and ill check the water-surface, its easy to remove semitransparent polis from it, but i might look too simple without it, maybe im just too graphic centered.

We can see that graphic is important for you, just by looking at your thorough texturing and lighting work.
It's just that curently, water surface is not displayed properly (it's blinking) and something should have to be done about this...

Well, we can forget this issue and the blue pixel issue for a while, but If you have a little time for it, could you just export the track again without the big dark polygon and send the.w file to me? I'd still like to try it with my world cutting tool.
If you can't find time for now, never mind, we'll wait for better days...

jigebren wrote:So, with the 'BigCubed' world file, I can get a more than doubled FPS on my system, which is already appreciable (from ~45 to ~145 at the starting grid position, for example).

You can download the modified world file (.w) here:
Jailhouse World with BigCubes.7z
I'm curious to see if anybody can notice the same FPS improvement. Also, thanks to report if you notice issues introduced with this file, to see if my tool is working nicely.
For example, there is some artifacts on the water surface, but they were already here with the original world file (so please check the original world file before reporting).

Also, I haven't specified it, but my FPS test were done in fullscreen mode. It'd be better to collect FPS in fullscreen mode only (I'm not sure windowed FPS is really consistent).
And have you noticed the level loading speedup? (on my system, it's pretty obvious).

I recently tried Jailhouse Rock, expecting nothing less than another suberb Human track.

Unfortunately the FPS stayed between 10 and 12 for the entire course, which is not playable, and the .w loads very slowly. However, the BigCubed version offers framerates between 30 and 75 (averaging 50-55 most of the time), which is very playable indeed, and the .w loads instantly.

An interesting point is that the original version offered almost no variation in the framerate, while the BigCubed version delivered a large and natural variation in the framerate.

The difference is amazing, jigebren! In my case you transformed the track from unusable to entirely usable, with a 3x/5x/7x increase in FPS, enabling me to see Human's artistic vision as intended.


I'm not sure if this is relevant but I used to change the farclip and fogstart values of laggy legos to improve framerates so I tried it here. Going as low as 1000 and as high as 40000 resulted in no changes to the framerate with either world. I wonder if that's due to the big polygon.


This thread and it's sister thread developed at the same time more than a year ago, I'm surprised at the silence since then. I'd love to see your utility published if only as something to experiment with. I'd like to try it on Sakura.

In any event, thank you for all of your excellent tool work.

Glad to see it has helped you in playing this great track.

In fact, I was practically sure I had already released this tool... But I imagine that if I haven't done, it's probably because it was still unfinished. And as I was (and still am) working on a lot of projects at the same time (v1.2, Blender IO plugin, WolR4, prm2hul, etc.), I can easily stall on one of them, all the more when not much interest is shown.
For info, I'm pretty sure that in the current state, this tool would break the TextureAnim (aka multiframe) and probably the Env color info of a track (as I was unaware of this at that time). Maybe it's not such a major issue as I think most user tracks don't use them anyway, so I maybe I could release it as is...

About jailhouse, some time ago I started to clean up/optimize the whole meshes (see my post dated Jun 15 2010, 02:02 AM), but this proved to take far too much time to fix everything and I dropped.

Well, I have work again on this utility as it seems it could be worth being released... (for info, this tool is able to merge/cut down/reorganize the meshes inside a .w world file so that polygons are regularly clustered in Cubes and BigCubes).

In fact TexAnim was already properly managed, but Env color would actually have been broken by this tool in the state I left it previously... There were also several potential issues with track using empty Cubes (the same issue SebR reported in the Blender IO addon topic).

I have updated the whole code, and added missing code to save/restore options, so I should be able to release it very soon (maybe tomorrow, if I have time to write a quick readme/doc...)