Our ReVolt Pub

Posted: **11 Oct 2011, 22:09**

The WorldCut utility can be downloaded from the Re-Volt stuff on my webpage.

WorldCut allows to update the content of a world file (.w) to properly use Cubes and BigCubes (in the same way as stock tracks).

Cubes and BigCubes are part of the World file format. They're both used in Re-Volt as way to improve the FPS, as they lessen the number of tests needed to know which polygons actually have to be rendered. The method is: if the current camera can't see a BigCube, all included Cubes can be skipped directly (not need to test them one by one). In the same way, if a Cubes can't be seen, all included polygons can be skipped directly. The opposite is also valid: if a Cube is fully included in the view frustum, all polygons will be rendered (no need to check them individually either). Of course, there is also the intermediary state (ie. a Cube is only partially visible, so polygons have to be checked one by one).

Posted: **11 Oct 2011, 22:45**

Following Wint suggestion, I have finally finished the tool I had used to release a version of Human's track "Jailhouse Rock" with (hopefully) an improved FPS. As it could be usefull for any track maker, I'm releasing it publicly now, under the highly inspired name "WorldCut"....

Here's an extract of the readme file:

readme.txt wrote:WorldCut is a tool for Acclaim's Re-Volt. It allows to update the content of a
world file (.w) to properly use Cubes and BigCubes (in the same way as stock
tracks).
For more info about Cubes and BigCubes, you can have a look at the following
two topics on ORP:
http://z3.invisionfree.com/Our_ReVolt_P ... topic=1412
http://z3.invisionfree.com/Our_ReVolt_P ... topic=1406

This tool is able to:
- merge all Cubes in a single Cube (one englobing BigCube is also created).
- remove duplicate vertices inside existing Cubes (based on vertices position
and normal vector).
- distribute the world's polygons in several Cubes along a virtual 3D grid
(the grid step can be set).
- associate the Cubes to englobing BigCubes. BigCubes are using another
virtual 3D grid with a greater step.

Though I have not thoroughly tested it yet, I've already tried it with stock tracks as well as extreme and lego user tracks without any noticeable issue, so I though it was not really worth a preliminary closed-beta release... Of course it should still be considered as a Beta version for now.

Check first post for the download link.

Using this tool on an improperly cutted out user track is likely to improve the FPS, though it is difficult to say how much. So if you're trying it on some tracks, it could be interesting to report here the average FPS before and after, as well as the used WorldCut settings (and the WorldCut Log)...

EDIT: Oh, and as you may have noticed, I have also updated the layout and content of my website, with a more convenient left menu, and a News section on the home page (and an up-to-date WolfR4 doc

). The Blender plugin page is yet to come...

Posted: **12 Oct 2011, 01:27**

Hey, this sounds great. I'm going to give it a run soon.

Don't know about the highly inspired name though.

I'd rather have choosen World Optimizer.

As mentioned in your website, "cubing" a world can enable re-volt to easily reject a cube mesh using visibox and camera tests. Another optimization is that the visible cubes are sorted and drawn in front-to-back order, which will significantly reduce "overdraw" (once the nearer cubes start covering the screen, the zbuffer can easily reject polygons in the farther cubes).

Oh, and about the website, there is a problem with IE. All pages in the website contain the following header, which triggers the browser into IE7 compatibility mode.

Code: Select all

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http&#58;//www.w3.org/TR/html4/strict.dtd">

Changing the headers simply to <!DOCTYPE html> should fix the problem, letting IE use it's native engine. Then the website should work fine in IE8 and above.

Code: Select all

<!DOCTYPE html>

I know at least one person who uses IE, and I think he'll be grateful if you make this change.

Posted: **12 Oct 2011, 10:25**

Thanks jigebren!!

I'm glad you released this because it's a powerful optimization tool.

In your Jailhouse Rock test I saw a 3x and 6x increase in FPS,
transforming the track from unplayable to very playable!

A low end PC will show more noticeable improvements with this tool, obviously,
so that's where a track maker can expect to get a meaningful benchmark.
A powerful PC that can handle anything isn't likely to reveal as much.

Bug report: Try Sakura.
WorldCut crashes shortly after it gets to CreateCubes {
I tried it on two different PCs and OSs with essentially the same results.

Posted: **12 Oct 2011, 19:28**

Oh hell, I tried Sakura too. After some CreateCubes calls with strange coordinates, the program hangs up and memory usage keeps increasing. But unfortunately it wouldn't crash till all my 2GB of memory + the 5GB hard disk page memory was used up, and Windows decided the PC is nuked. Next time I try cubing Sakura would be in a virtual machine.

Offtopic:
Thanks for changing the doctype in your website.

I also had to disable the use of Microsoft's "compatibility blacklist" (free.fr domain was probably added to the list), but now it renders fine. MS's decision to use a legacy rendering engine without the user's consent or knowledge is pretty weird. For example all Invisionfree forums have no doctype header and they're always rendered in IE5 Quirks mode.

Posted: **13 Oct 2011, 06:22**

Ok, the Sakura bug is fixed. As this track is using more than 32767 polygon, there was an issue with signed/unsigned variables.

About the increasing memory consumption, though it could be an outcome of the previous bug, there was also another issue: I noticed that the memory consumption could easily reach more than 500MB, which was really weird for this tool... I double checked everything but it was still here. I have had to trim down the code to locate the issue, and in fact it revealed to be a PureBasic bug (v4.51)...
I was about the submit a report, but there was still a new 4.60 RC release I have not tried yet. And it fixes the issue.

So, though it's still a RC, I have used it to compile the last WorldCut release, and everything is looking fine now.

Thanks you both for the reports. The updated release can be found on my website.

Offtopic:
And thanks Huki for the tip about DOCTYPE. Well, I'm still using Kompozer and it only supports very few DOCTYPEs, but apparently it doesn't overwrite it if I update the files myself.
BTW, I was thinking about simply dropping Kompozer and editing the html/css directly now (ie. the true way, in a simple text editor), but well, I'm not really sure I'm ripe to leave WYSIWYG editing...

Posted: **11 Nov 2011, 06:40**

Due to another PureBasic nasty bug, the last WorldCut release produced corrupted files (at least when I tried it again on Jailhouse Rock track).
I'm surprized that nobody noticed it before, so either it does not occur on all tracks or nobody actually use this tool...
Hey, where are you the advanced track makers?

Anyhow, a new relase fixing this bug can be found on my website. It also features several minor internal as well as cosmetic changes.

Just for info, I noticed that when using a BigCubes size smaller than 4000 with Jailhouse, it leads to weird result with transparent texture in Re-Volt (they appear more opaque than they should). I don't kow yet the reason of this weird glitch, but it could be a Re-Volt bug caused by Jailhouse exceeding some of the internal limitations...

Posted: **11 Nov 2011, 07:38**

jigebren @ Nov 10 2011, 09:10 PM wrote: Anyhow, a new relase fixing this bug can be found on my website. It also features several minor internal as well as cosmetic changes.

Just for info, I noticed that when using a BigCubes size smaller than 4000 with Jailhouse, it leads to weird result with transparent texture in Re-Volt (they appear more opaque than they should). I don't kow yet the reason of this weird glitch, but it could be a Re-Volt bug caused by Jailhouse exceeding some of the internal limitations...

While I'm at it, might as well tell everyone what i've found when i played with this little tool.

I used it on a Lego-Extreme track I've got in the works, with visiboxes, and on my other pc it gets about 20 fps in areas that i didn't visibox. Well... the track has been RV-glue'd to death, and I even added a fully extreme section into it. But enough about the track.

When I ran WorldCut with the default settings on, I didn't get any FPS increases anywhere... in fact, I ran a grand total of 5 FPS (if i'm lucky) in most areas. However, when I increased the Cube size and scale factor, I managed to get an increase to about 25 FPS. Not sure what I used, but I increased that AND played with the 5 actions you have available (haven't tried the most recent version).

And about the transparent textures? The track I tested worldcut on had some transparent polies, but it didn't give me any problems. But then again, the track isn't quite pushing Re-Volt's limits like Jailhouse Rock... so nothing there, i guess. Perhaps it's an issue with Jailhouse Rock rather than WorldCut...

jig wrote:Due to another PureBasic nasty bug, the last WorldCut release produced corrupted files (at least when I tried it again on Jailhouse Rock track).

No corrupted files here.

jig wrote:Hey, where are you the advanced track makers?

Oh, please, don't be so kind...

Posted: **11 Nov 2011, 14:35**

I got to be honest Jig I am still waiting.
After the total mess with the last track as far as the " we dont realy use wolf any more" after i had such cool ideas i had to scrap along with many many hours down the pan, I am more inclined to wait untill all of this cool stuff is combined into one package along with tutorials for creators like me who arn't to good at learning all of the list file, batch, c + ,code stuff lol
If i know enough people will use the tracks i want to make i would be cranking into it full on but at the moment, for the amount of time it takes to make a full custom for some members to call it a lego extreme it sort of lowers the enthusiasm

Yes i am a whining bioch and i sulk alot, but hey youll just have to put up with me and wait for my obligitory christmas Zero degrees track lol

I really love what you guys are doing with the game but i do hope you all come together sooner rather than later and make a total custom track package for me to play with.
My other main concern is the whole texture res thing. Am i right in saying that i will be able to use textures of any res ?? and can the textures be of any size like they are in most games today? if so it would totaly transform Re-Volt tracks.
Thanks peeps...
Mike....

Posted: **11 Nov 2011, 18:11**

[semi-offtopic]I feel kinda the same about the upcoming car AI updates. I don’t know whether to keep making cars optimised for the old AI or to stop everything and wait for the new AI.[/semi-offtopic]

Posted: **11 Nov 2011, 18:39**

Just something I'd like to add that I forgot in my last post: It is _VERY_ possible that I may not have seen a huge increase because the chances for duplicate vertices in all-instance tracks (especially mine

) is pretty low. What I mean is that I probably didn't place the instances that make up the track's world file as precisely as one can in a 3D modeler, and that wouldn't really bring up my track's FPS, because there weren't many duplicate vertices to get rid of

Mike wrote:My other main concern is the whole texture res thing. Am i right in saying that i will be able to use textures of any res ?? and can the textures be of any size like they are in most games today?

[not really helping]Well, as of right now, Re-Volt supports up to 2048x2048 textures, and also, jig himself said that the next 1.2 release will support custom models:

jig in the 1.2 development thread wrote:BTW, the next v1.2 release should support custom model. 
It will be a bit less thorough than with WolfR4 (it will not be possible to modify Objects properties as in the custom.ini file) but it will be very easy to use: the custom models just have to be placed in the track directory to be detected when the track is loaded.
For example, if a "pickup.m" file is found in the track directory, it will be used instead of the default model...

So maybe you'll have some big textures and custom models to play with?

Posted: **11 Nov 2011, 21:17**

Huki has just suggested me an idea that is very likely to explain the issue with transparent textures affected by the BigCube size, and maybe some other glitches too... And it would be an issue with WorldCut itself (which in some way rather comes as good news...).
I'll double check the whole code ASAP and it should be ok (hey, please remember that I worked on this tool in an erratic way, and when I read the code several months later I may have forgotten that some parts were not really polished).

[Offtopic]

About v1.2 textures support, it should be ok as long as you stick with square textures and power of two sizes (ie. 256x256, 512x512, 1024x1024, 2048x2048).

About WolfR4, I think it still used, but not by online players who prefer v1.2... I understand you don't feel like working with a tool that sounds deprecated already. On the other hand, if you create a great track using WolfR4:
1) it will likely be portable to v1.2 eventually. For example, Jailhouse custom was created with simple Batch files, then it has easily been ported to WolfR4, and now it can be ported to v1.2.
2) it will also help us to see which are the most needed feature to implement in v1.2. Huki and I are both devs and players, and we will more likely implement a new feature if we know it will allow us to play a great track in v1.2. For example I've added custom skybox support just to play Skyscrapers...

About custom models support in v1.2, I can confirm it's working now. There was also a great internal rewriting to be able to use the 3D sounds from any stock tracks in an user track (each sound also being customizable). But there will be no other custom features, at least for now (like custom cameras or custom object properties).

It's too bad we can't release a new v1.2 sooner, but we've worked on several features at the same time, and we can't release a new version before everything is at least in an usable state. In short, to release the custom support, we have to finish working on the AI before...

Posted: **11 Nov 2011, 22:45**

Ok, the glitch with BigCubes and semi-transparent texture is fixed now. In fact it was just the same nasty PureBasic bug but elsewhere in the code... For info it could also lead to a lower FPS as some meshes (ie. Cubes) could be drawn several times.
If you have already downloaded release 11/11/11, please re-download it (the readme has been updated).

If you have already used this tool on some tracks, please run it again with the updated release (you don't have to delete the previously updated .w file as the data are always read from the backup file).

Thanks again Huki to have pinpointed the issue.

Posted: **05 Apr 2015, 20:48**

I need help to understand "Remove dulicate vertices" options ...

"Min normals angle:" is not easy to understand

Posted: **05 Apr 2015, 22:23**

I think it means duplicate vertices.

Posted: **06 Apr 2015, 04:06**

A vertex in Re-Volt holds both a location and a normal orientation informations (the latter being used eg. for ENV and for lights as well sometime I think). It means that to use different normal orientations for a face on one side of an edge and a face on the other side, let's call them face A and face B, then face A and face B won't share the same vertices along this edge (as it's usually done). Instead, each will use its own vertices. The vertices used by face A will have the exact same position than the vertices used by face B, but the vertices normal informations will be different.

Take the Toyeca as an example. The roof + windows part is separated from the rest of the body, that way the edges below the windows use different vertices for the faces below (the body) and the faces above (the windows), even tough the vertices location are the same. That way, these edges will look "sharp".

So to remove duplicates, it was not enough to check only the location (otherwise we would lose any sharp edge done on purpose). When two vertices share the same location, WorldCut also check the angle between the vertices normals. Only if this angle is below the given value the vertices will actually be merged.

I have used "Min distance:" and "Min angle:" but it occurs to me now it could be a bit misleading, as "Max" could do the job just as well... You should rather think of it as "Merge distance below:" and "Merge angle below:".

Is everything clear now, or do you also wonder about the options in the left panel?

Posted: **06 Apr 2015, 19:00**

Thanks I understand why there are normals at each vertex

And here is how I understand the left pannel :

If I choose actions 1, 2, 3, 5
Then all world will be merged in only 1 cube, then WorldCut look at all possibles duplicate vertice on this bigcube and after split world in cubes and made bigcubes according new cubes

If I choose actions 1, 3, 4, 5
Then all world will be merged in only 1 cube, then WorldCut split world in cubes and in each new created cube look for duplicate vertices (but if there is the same vertice in 2 differents cubes, we still have 2 vertices) and made bigcubes according new cubes

note: I know it's not the good place but why vertex have normal on ncp too ?
Is the "sharp" looking in W/PRM become realy "sharp" on NCP ? (that can explaine somme "invisible wall" on custom tracks)

Posted: **06 Apr 2015, 20:16**

For actions 1, 3, 4, 5, it's a bit more subtle...

First, to clarify a point, each cube has its own vertices list. It means that even if it look like two cubes share a vertex, internally there's always two vertices. They can be perfectly equal (same location & same normal) but it's not *the same* vertex.

The only difference between actions 1, 2, 3, 5 and 1, 3, 4, 5 is in case two cubes have similar but not exactly equal vertices.
- In the first case we merge the cubes, then we look for dups. In that case the two vertices will be merged into one average single one. Even if this vertex is split again between two cubes when cutting out the world (action 3), we're sure each cube will use the exact same location and normal for this vertices, that is to say the average one computed before.
- In the second case, each cube can still use its original vertex, that is to say before averaging.

To make it short, first case makes a safer and more thorough job, but can be much slower. Second case does not guarantee that similar vertices (but only if they are in different cubes both before and after cutting the world !) are detected as dups. But it's likely much faster to proceed...