Our ReVolt Pub

hello,
can i ask if anybody knows the limitation of viziboxes, i dont suddenly find any topic talking about this, what is the maximum for cameras and boxes in total or/and separately?
the reason is, im finishing up my track and cant insert any more boxes, insert button stopped working, which according my experiences means limit has been reached.

according to Re-Volt source:

#define VISIBOX_MAX 400
#define VISIBOX_MAX_ID 64

max visiboxes that can be inserted into makeitgood are 64, but you can insert without that mode 400 ones...

ok thats 64 camera box, in other words 64 sets of boxes, but how many corresponding boxes for the camera boxes?
lets say i have got 52 cameras. how many boxes can i insert for each, and how many in total?
again, what is this number for ase2viz, i understand that theres a number (400) but what does it refer to? cameras, or boxes or both?

hold on, is that line that you quoted not to be understood like this?:

max ID=64 (which means no camera(box) or box numbered with a higher number)
max vizibox 400= total number of boxes cant be more than 400, and thats including camera(boxe)s and boxes as well?

this seems to be making more sense to me.

Visibox limit?

Not just visibox!

Track zones, triggers and farce fields too!

So bad .

I can only answer: ase2vis is able to output max to 400 viz

makeitgood mode only enable you to insert a total of 2^6 (64) of vizi

The limit might not be a number of cubes and boxes but rather
the .viz file size. I know some edit modes max out at 12k in file size.

well, i dont know, the file is 16,4 kb.
im not going to count the cubes
by he way thats what i said wrong, the cubes, i kept calling them boxes, sorry, i meant cubes

Hey Human
How old will I be when you get dun with
the new track?

Two old to push the buttons?
So blind I can not see the track?
Cant get out of my bed?

Just kidding!
Im still here.
Kinda

haha, ricky,
sorry for my tempo, no time, thats the problem.
and thanks for being interested,
just a few days i promise, i hope you will like the track.

rickyd @ Dec 28 2009, 03:29 PM wrote: Cant get out of my bed?

If it comes to that, just get a laptop.

Ya ill be here.
Looking forward.
Can't wait.

I think we should be trying to figure out these other "Fuzzie balls???" coz looking at the polie structure in a stock track they must do a fantastic job at increasing rate.

Skitch2 @ Jan 1 2010, 03:07 PM wrote: coz looking at the polie structure in a stock track they must do a fantastic job at increasing rate.

can you re-phrase this mike, i dont understand.

Edit: ahh, you mean the frame rate? do you mean the original tracks are high poli?

yea they are made up entirely of 250 x 250 generic units in max or divides of 250x250.
I have recreated sections like it before and filled the ncp limit 16k vizzed it fully and it runs like a bucket of poop. Vizz, Farclip, fog, bmqs all in so it must be that the original artists had another trick in the engine to smooth things out and i believe it to be funny balls. Look at muse 1 closely and youll see that it is a MEGA!! poly structure.

Quite interesting! Earlier I thought that it was because of the mass use of Instances blended with the w file that did the job.
As an example I got 2 of my tracks created using either one of the methods. Forgotten City is made of Instances (unglued), but has a tendency to crash by loading it after Re-Volt already has loaded it once. JungleVolt is 55000 polys, in it's world file, but is using the fin file for vertex skymap-parts (No lag reports). And then there is Radioactive Garden which uses world file only and is half as lowpoly compared to JungleVolt. For some reason it appears to lag on Zach's and Ricky's machines and I have no idea why.

I hope Skindup might be able to tell us more about that, when he digs a bit more into it. Or maybe we should just ask Simon Harrison. I aleready got the max version of Museum and Garden as 3ds files from him, if that interests you.



Gmax tells me that Museum2 only is 12460 polygons, though. Could you please explain a bit further what you mean by high-poly?

Cool urne, is that a new track from you?

urne, i think we shouldnt make the original 3ds files available to the open public, i think the community should keep it for people who are trustworthy and competent. i downloaded the files, they are hugely valuable in my eyes, i just already fear for them, i dont want to visit rvzt one day and notice a new track called museum 2417 which is a repaint of this treasure with idiotic textures and full of incongruous stuff. what do you think?

Mayabe its the way its pulled from the game as the one I had was made entirely from 250x250 unit polies, hunners of them

In your model its seems to show the main walls as tall polies, this is not how the track is made, it is imposable to texture the track without the poly size being 250 or divides of. this can be seen by studying the texturs in the track and unless they had a way of tiling texture, (which would interest me fully) plus this is also muse2 not i and muse1 is way higher poly.

The Lag on diferent mapps will probably be to do with the maths, in referenceto the relationship between the poly size and the Re-Volt far clip.
The far-clip has to pass over the poly in order to clip it from the render-er and it is far more efficient to do this in small increments than to leave a poly rendered while not seen behind the fog start. After years of playing with this system it realy does work out that building the track using poly sizes of 500x500 generic units as a maximum to keep the poly count lower (coz i think that the funnyballs play a part in all this) and then keeping poly sizes 250 halved to, 125 then, 62.5, 31.25 and so on keeps frame rate higher by fully utilising the far clip system.

If this seems to be a load of tosh to any of you please let me know and save me from a load of max hell lmao

Human wrote:urne, i think we shouldnt make the original 3ds files available to the open public, i think the community should keep it for people who are trustworthy and competent. i downloaded the files, they are hugely valuable in my eyes, i just already fear for them, i dont want to visit rvzt one day and notice a new track called museum 2417 which is a repaint of this treasure with idiotic textures and full of incongruous stuff. what do you think?

I removed the zip for your sake, human. Well, I can also see what your point is.

Skitch2 wrote:Mayabe its the way its pulled from the game as the one I had was made entirely from 250x250 unit polies, hunners of them

In your model its seems to show the main walls as tall polies, this is not how the track is made, it is imposable to texture the track without the poly size being 250 or divides of. this can be seen by studying the texturs in the track and unless they had a way of tiling texture, (which would interest me fully) plus this is also muse2 not i and muse1 is way higher poly.

Simon Harrison wrote to me that the track designers were using max to create the meshes, but used an in-house tool with the name "Habitat" to do all the texturing and exporting. Unfortunately he also writes that over the years he lost it aswell as the other utils and exporters. The 3DS files he attached to the e-mail is (if I understood right) how the meshes looked like when they went into Habitat. If you are interested I can forward the e-mail to both of you.

Your theory is very interesting, Skitch. It sound to me like you are talking about a system that functions just like mip-maps, making the track lowpolyer the longer away you are from the farclip. Does Lego tracks use this too?

miromiro @ Jan 3 2010, 01:20 AM wrote: Cool urne, is that a new track from you?

What the f*c*?
Don't you see my question?

miromiro @ Jan 3 2010, 12:15 PM wrote:

miromiro @ Jan 3 2010, 01:20 AM wrote: Cool urne, is that a new track from you?

What the f*c*?
Don't you see my question?

that's museum2 (of Re-Volt)
...

_

high poly of NCP is what are we talking about (16k polies of NCP may destroy the track)

Okay, sorry.

Skitch2 @ Jan 3 2010, 08:13 AM wrote:In your model its seems to show the main walls as tall polies, this is not how the track is made, it is imposable to texture the track without the poly size being 250 or divides of.

After years of playing with this system it realy does work out that building the track using poly sizes of 500x500 generic units as a maximum to keep the poly count lower (coz i think that the funnyballs play a part in all this) and then keeping poly sizes 250 halved to, 125 then, 62.5, 31.25 and so on keeps frame rate higher by fully utilising the far clip system.

If this seems to be a load of tosh to any of you please let me know and save me from a load of max hell lmao

mike the above picture shows the shaded polis but if you turn on the edge display you can see that the track is built exactly the way you are describing it. its built from very consistent size polis, they form a fairly even mesh.

your theory does make sense, if i was a farclip, i would prefer lots of identical size polis, i would hate odd shape and odd size ones . its quite logical what you are saying. by the way the same thing helps the track look pretty texture-wise i think, 256 pixels dont look very smart on big polis.

The 3DS files he attached to the e-mail is (if I understood right) how the meshes looked like when they went into Habitat. If you are interested I can forward the e-mail to both of you.

of course!!! every little crumbs from the original authors is hugely valuable and interests me very much. this habitat thing is very very interesting, max knows a lot of way of texturing, but ase2w doesnt understand them, it only converts one or two methods. if i could see this texturing tool... i am sure it was created only for the game, because there is literally nothing on the web about this habitat.

I have realy put the small poly count verses the large poly count to the test over the years and it definitely effects the frame rate, also the more objects you make in your mesh (break every vertex) will improve frame rate.

mike, are you saying that if i make a big room with lots of tables and chairs and windows and i save and convert it in two versions:

1. all the bits and bobs are individual objects
2. everything attached together, vertex points welded, one huge object

then the first one will definitely have a much higher frame rate?

The one broken up into all its singular polies (break all the verts) wil run smoother in game.
The one that is a whole lump will run slower.
Breaking the mesh down also helps in many other ways like....
The ase2w will process the mesh at a much faster rate.
Any errors in the mesh can be identified and fixed far easier. (vert normals are not normal they are zero) <being a good example as it tells you what object has the error and you can locate it in max almost instantly with the selection floater.
You have to make sure that breaking the verts in the mesh is the last thing you do on completion, as vert shading is way harder when the mesh is in bits.

I used to have to use all these methods before you guys were about because i was making tracks like "Mines of Alderon" on a Pentium 90 with a voodoo2 card. I noticed all the benefits far better back then than today but it must still take the strain of of the tracks rendering tasks.

My PC was so slow back then that when I selected all of the verts in med mayhem it took 3 hours for max the explode the mesh lol, ohh the days hehe

have you got any solution for the flickering edges that appear when the vertex points are broken, also when a shockwave is launched, the poligons move individually, not in a nice chain reaction.

To be honest with you dood, I have never noticed any of that lol.

well thats interesting because one of the very few reasons why i weld vertex points is those edges flickering why moving the car around, looking not smart at all. maybe i should have a look on my vertex snap settings.

listen mike, when you explode your mesh, what do you set the 0-180 slider to?

Is exploding mainly the same as breaking the vertexes? In that case, I wonder why both features has been made.

Hey Urne
I would like to look at those max file.
Can you send them to me?
Do you know my e-mail?
Talk 2 U

urnemanden @ Jan 3 2010, 09:42 PM wrote:Is exploding mainly the same as breaking the vertexes? In that case, I wonder why both features has been made.

well in my understanding braking vertex point results in having individual poligons within one object and exploding a mesh which is still one object results in having many individual objects
i think mike performs both, but he will probably explain it.

mike, listen,
i made an experiment with this vertex braking thing on my track before releasing it (will happen probably on tuesday)

my original mesh is an editable poli. it consists of a lot of individual models, but i attached them together and the main body of the track is basically one object only.
all the vertex points were welded.

i saved and converted another version after braking all the vertex points. i tried to explode the mesh as well but max died i tried it a few times, couldnt manage it, it froze.

now, i recorded the file sizes, track loading time, and fps on several points of the track, on four points where its easy and safe to find the same position for another test) the results are the followings:

world file size before: 2,26 mb world file size after: 2,39 mb
loading time before: 18 mp, after 18 mp (a lot, i know, dunno why)
fps on checkpoints
1. before 31 after 27
2. before 31 after 28
3. before 28 after 24
4. before 28 after 25

now as you see this is not exactly what i expected according to your theory, what do you think, there can be other factors of course.

RickyD wrote:Hey Urne
I would like to look at those max file.
Can you send them to me?
Do you know my e-mail?
Talk 2 U&nbsp;

Delivery to the following recipient failed permanently:

rickyd@ise10.tv

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.1.1 User unknown (state 14).

urnemanden @ Jan 4 2010, 12:57 PM wrote: but it was rejected by the recipient domain.

sometimes isp-s get blacklisted because of a high number of spammers from the same isp/server, usually they get unlisted themselves in a day (the bigger the isp, the sooner), if that is ricky's mailbox, you can probably send the mail soon again.

Sorry that tv channel went off the air.
And so did my e-mail.
This is my new e-mail
rickh@cmc.net
This one works.
Thanks Urne!