Blocksburg
User avatar
C2_Scientist created Blocksburg on Fri Mar 02, 2012 12:26 pm
Post
Hello,

I've been reading about modular modeling, which basically means creating various tileable 3D pieces which can be quickly cloned and positioned next to each other, in order to easily create a large amount of different combinations. More pieces = much more variety and combinations, and some pieces could be re-scaled and mirrored too, where applicable.

Here's a simple example:

Image

Other than buildings, it should work well for road related stuff too, especially in cities. A bit like modeling with Lego pieces. :)

As for in-game performance. It's probably memory efficient since there's only (relatively) few simple pieces to load which are multiplied as instanced copies... but on the other hand, using modular pieces to model things typically also increases the total polycount. Think of a long, simple wall made of multiple squarish quads instead of a single long quad. This may make it less feasible, unless there's some technical stuff I'm not aware of. :)

Lastly, here's a link to a bit more reading.

http://www.gamasutra.com/view/feature/2475/

(January 24th: Changed thread title)


Last edited by C2_Scientist on Thu Jan 24, 2013 10:22 am, edited 1 time in total.
User avatar
Toshiba-3 on Fri Mar 02, 2012 1:28 pm
Post
Yeah already thought about that often.
Too bad we can't use it really for C2. Unless we'd use static noncars or someth...

Now that I think about it, it might be possible but kind of laborious.
If elements have their actor ID starting with $ they won't be merged in the track mesh during the preprocessing.
They'll stay actors but won't be noncars. At the moment I can't remember whether they'd have collision or not.
But anyway, if done properly we could have all these instances of a same module and there'd be only one model in the DAT. Ingame polycount would be a bit higher as you implied but resources could actually be way lower.

A good track concept to test that would be to reproduce one of these StarCraft 1 interior missions there. The ones inside ennemies bases. Long corridors with round corners etc. All built on a grid.

Adding the link to the intersting article topics :ssmile:
Image / carmageddon add-ons at road reaction
User avatar
Harmalarm on Fri Mar 02, 2012 2:41 pm
Post
Quote:
At the moment I can't remember whether they'd have collision or not.
But anyway, if done properly we could have all these instances of a same module and there'd be only one model in the DAT. Ingame polycount would be a bit higher as you implied but resources could actually be way lower.


definitely! I did some tests with my scriptpack. Buy the way, the prefix is &, not $... ;)
If you check out the test track I supplied, you will notice that the poles under the road are instanced models. (The script instances model by default if they have the & prefix.) It turns out the collisions are working fabulously.
So this concept will absolutely work. I still wonder whether c2 has limits regarding instanced models. We should do some tests with this.
User avatar
Toshiba-3 on Fri Mar 02, 2012 2:46 pm
Post
Quote:
We should do some tests with this.

We'll turn into GLaDOS someday. More and more tests. For science.

And yeah I always get mixed up with $ & and £...
Image / carmageddon add-ons at road reaction
User avatar
C2_Scientist on Fri Mar 02, 2012 2:54 pm
Post
Hah! I was already wondering what's this new "$", and what does it do. ;)

While on a walk, I tried to visualize how the various houses could be built of modular tiles. This could be quite useful, if it will work reliably in C2.

Edit:

Regarding the image above, I forgot to mention: since the plinth is a separate model and not included in the wall tiles, the tiles can also be used to construct a high-rise building (otherwise there would be a 'stripe' of plinth between each floor). That means more versatility. :)
User avatar
C2_Scientist on Sat Mar 03, 2012 12:05 pm
Post
Here's an intersection built using road pieces:

Image

It would probably make sense to make slightly longer sidewalk blocks, to reduce the polycount. :)
User avatar
Toshiba-3 on Sat Mar 03, 2012 12:09 pm
Post
Looking at your crossroad there, I suddenly remember I still have the GTA/GTA2 cities!
Problem with them wasn't the geometry but the amount of small textures :(

Cities were too big to have a great gameplay but it would have been a good way to use that modular design idea.
Image / carmageddon add-ons at road reaction
User avatar
C2_Scientist on Sat Mar 03, 2012 8:35 pm
Post
Yeah, I recall the second GTA has a lot of texture variety since there are areas of many different themes (such as the bases of different factions), while the first one seemed to use a much more generic set.

It could be interesting to see the GTA cities viewed from a different camera angle and perspective, such as isometric view or just plain 3D. Do you have them in Max in order to make a quick render?

Also, to expand the first image: some more building blocks, and material variations.

Image
User avatar
Toshiba-3 on Sun Mar 04, 2012 8:35 pm
Post
This is all I could find, first is GTA1 second is GTA2. Can't remember which cities to be honest.
I could make renders in MAX, but I can also share the whole things with you if you want?!

Image Image

The second one clearly shows how huge it is!

Your pieces look good btw. You should have a go with Harm's CarmaTools to see how it behaves ingame :)
Image / carmageddon add-ons at road reaction
User avatar
C2_Scientist on Mon Mar 05, 2012 2:03 am
Post
I could have a look out of curiosity, if it's not too much trouble to pack up and upload. :)

Thanks for the images too. The right one is more to what I was thinking of: the city looks good enough when its details are not viewed too close up, heh. The left one isn't too pretty. :)

As for the main topic, I'll build a small city test scene (street pieces and a few high-rises), and try it out in-game. It should be relatively quick to create now that I have decent set of blocks done.
User avatar
Harmalarm on Mon Mar 05, 2012 1:20 pm
Post
Very interesting looking set of models you have there! I think most pro's and negatives abou modular design have been said already, so there isn't much else to do than test. It reminds me of a conversion I still have on the shelf, a track from revolt. It doesnt use instanced models, but does use a lot of atlassed textures. Reminds me to release it again. :)
User avatar
Toshiba-3 on Tue Mar 06, 2012 1:38 am
Post
Ok, I sorted the GTA1/2 stuff (haven't touched that since 2006/2007).

I only have an ASE file for the GTA1 NYC map (the one I had imported). However I seem to have the textures of the three cities. I don't have the MAX scene anymore nor the C2 test track. Should be fairly easy to import in MAX.

For GTA2: I have the three cities map files (bil, ste, wil) and their tons of textures. I only included the TGAs with hex filenames because it is required by the map importer. However I rememer that back then there was an offset in the filename and I had fixed it for the BIL city, the one I imported into MAX then C2. STE and WIL textures still have that offset problem, you'll directly feel it in MAX, something's wrong when the textures are applied. Here I have included the MAX scene for BIL. You'll easely get that ingame if you want to. Some textures won't load though (too many of them).
For the two other cities (if you wanna bother), you'll have to use the map_importer maxscript and have added the folder with the TGAs to MAX's paths. Once the importer is done, use the Activate All Textures from the material editor window. Or use the included all_textures maxscript. You'll then notice the texture filenames offset. The offset isn't high, you can compare the road textures to try to sort it out. ...Or water texture, that should be easy.

There's also a map renderer in the pack. Doesn't work anymore here. Old delphi libs I guess.

All this was handed to me by Jernej L., a famous dev from the GTA community. He used to run gtatools.com.
My latest idea was to make a redux of the city, making it much smaller (to improve the gameplay and lower the texture count) and replace the "accessories" by 3d models (like lamppoles or bridges, their alphas are black).
As you said, I doubt there'd be anything to do with the GTA1 ones even if they are smaller and have less textures. But the GTA2 ones have that gritty feeling. Makes me wanna play GTA2 again.

Ah yes, the download link: http://rr2000.toshiba-3.com/R6/gta1n2_maps.rar

Anybody can download the pack and have a go (as long as it's there), few people will have an actual interest in it though. This stuff is pretty rare, I doubt the gta tracks are still on the net (or ever were) in this usable format. (didn't check though)

's all! Good luck!

[edit!] Had a look! Found more stuff there: http://www.ukscifi.net/gtatools/
nyc-max.rar, sanb-max.rar and miami.rar should be MAX8+textures stuff.

And here are the GTA2 ones: http://media.gtanet.com/hosted/gtatools ... 2_max8.rar

How awesome... that gta2_max8 rar file is the very one I sent to Jernej in november 2006 following our email exchanges. He shared it and people saved the stuff.

INTERNET..!
Image / carmageddon add-ons at road reaction
User avatar
coffeycup on Tue Mar 06, 2012 1:45 pm
Post
Yeah, the model railroading community has been doing the modular tiles for a while now. They do it so that they can easily move and setup a layout at a tradeshow convention. They'll agree upon a standard for the dimensions and then different people can create the individual tiles and then it (hopefully) all fits together seamlessly.
MacCarpocalypse | coffey.polygonized.com | CoffeyCup's Gallery
User avatar
C2_Scientist on Tue Mar 06, 2012 10:07 pm
Post
Thanks for the links, they were very easy to open too. :) The cities look like sort of a chaotic tetris when you zoom the extents in top view.

Some progress too. Created more blocks, some high-rises, and started with the test scene:

Image
Image

The scale looks mostly ok to me.

I had forgotten that objects mirrored in Max will flip their normals ingame, so I will have to avoid doing that. The images look fine because the offending materials are temporarily twosided.

I've also made longer duplicates of some blocks, multiplying their relevant dimension to the power of two: 1x1 blocks -> 2x1 blocks -> 4x1 -> 8x1 and so on, up to reasonable numbers. So to fill a gap of 14x1, you would use 8x1, 4x1 and 2x1.

Another related trick that should work to fill gaps (have to test more) is simply re-scaling some blocks. It works at least with organic materials where texture tiling won't easily give away the scaling. It won't look good on blocks using materials that tile in an obvious manner. For example... well, tiles! :)
User avatar
Harmalarm on Wed Mar 07, 2012 8:39 am
Post
Wow you are fast! This is starting to look real promising.

There is probably no other way then to create a second object for parts that need to be flipped. Or you might be able to rotate them? Scaling them -100% will also flip the normals probably?

Where are you planning to go from here? Will this be a full game track?
User avatar
C2_Scientist on Wed Mar 07, 2012 9:27 am
Post
True, but fortunately most of the offending blocks can indeed be 'mirrored' by rotating them, and when necessary, truly mirrored duplicates are also quick to create. :)

I will keep expanding the set of blocks and creating scenery with them, so I guess I might as well make it a full addon map. Hopefully decent sized as well.

EDIT:

I've run into a problem. The exported track in the previous images apparently wasn't using instanced copies yet (the model list was very bloated). After an attempt to fix it, I get this in Plaything (top view):

Image

Quite a mess, but besides most blocks being mispositioned, it looks like some pieces are also missing, or perhaps replaced by others. However, some partial areas also seem to be intact. Time to put the thinking cap on...

If you're interested in running your own export tests, or just want to check out how the concept works in Max, here's a link to a ZIP file:

http://c2s.toshiba-3.com/DLoads/MaxBlocks.zip
User avatar
Harmalarm on Wed Mar 07, 2012 6:38 pm
Post
I had some trouble getting your set working. Turned out I had to convert everything to editable poly. Also there was an error in one of the tiles. After deleting it the track exported and loaded up fine using my max tool.

I noticed you worked in 100x carma scale? I would be careful with this, if you ever plan to use my script. Max remembers the inherent scale of an object, so either you have to reset the Xform of the object when it is scaled to proper in-game scale, or you have to model it this way. Resetting the Xform however, also removes rotation and deliberate scaling differences, so you would have to replace all you instances again...

Image

I renamed some of the similar objects with the prefix '&' so that the game will see them as instances. Turns out that there is in fact a collision error. This might be because of my script, or because of the game. I did some further tests on my test-track, and I noticed that up-scaling an instanced object made it's collision unreliable. It still collided somewhat, but not the way it should.
However, if the object stays in the same scale and orientation, the concept still works very well.

about the number of instances, I tested with 2400+, still no crash or error... seems the game can have quite many.

Image

I wonder if you get the same collision error when you do everything via plaything, e.g. if the error is in my code somewhere.
User avatar
Toshiba-3 on Wed Mar 07, 2012 6:56 pm
Post
Nice work there.

Quote:
about the number of instances, I tested with 2400+, still no crash or error... seems the game can have quite many.


Yeah but IMO you should try hitting a lot of these instances and then hit a moveable noncar just to be sure it hasn't frozen. (Remember the problems with noncars in SpeedBowl).

What about the roads can they be an instanced model with collision with no further gameplay problem?
Image / carmageddon add-ons at road reaction
User avatar
C2_Scientist on Wed Mar 07, 2012 9:07 pm
Post
I thought all objects were already converted to editable polies. They were intentionally left without the "&" character in object names, in case anyone wanted to try exporting without it. I figured everyone has downloaded some sort of a mass rename script. :)

But if I understood you managed to completely evade the "scrambled objects" problem? Also, were you able to pin down the problematic tile, and the problem with it (if it makes any difference)?

I wasn't aware of the problem with the different working scale, or I had forgotten it. But I suppose I could scale down everything, by 128. This would retain the easy tileability with grid - for example, a basic piece would then have dimensions of 1x1 units. I'm not that far with my progress yet, so it wouldn't matter hugely if I had to redo the current scenery.

Quote:
I noticed that up-scaling an instanced object made it's collision unreliable.


Well that's just my luck, it was too useful to be true. :)

EDIT 1:

By the way, is there a "move active object to mouse clicked position" function/script in Max?

EDIT 2:

I've updated the ZIP file (http://c2s.toshiba-3.com/DLoads/MaxBlocks.zip).

If you want, follow the steps of these three cases on a backup copy, and see if you get similar results:

A)

1) Use the "Select by name" dialog to find and delete all "Shape" objects
2) Use the same dialog to find and ungroup all "Group" objects
3) Select all remaining objects, and "convert to editable poly". This step removes the instancing.
4) Scale down to 0.5% (1/200)
5) Export and try in-game.

Result: everything should look ok, but the objects are not really instanced in this case.

B) Follow the previous steps, except before step 5, use mass rename to add the "&" prefix to objects. The result should be scrambled object positioning, missing objects and false instancing.

C) Follow the steps of case A, except step 3. The result should be that the scene in-game looks mostly empty, except for some pieces. If you open the SDF in Plaything, it should repeatedly ask you to locate models.
User avatar
n3wton on Wed Mar 07, 2012 11:04 pm
Post
sooo good to have devwam back! ;) dont know you are talking about here most of the time, but screenshots = great stuff!
Image
User avatar
Harmalarm on Thu Mar 08, 2012 11:39 am
Post
Quote:
I thought all objects were already converted to editable polies.


yes, they where... I think it had to do with the corrupt object, which I haven't pinpointed yet btw.

Quote:
But I suppose I could scale down everything, by 128.


Yes. Just be sure to reset the Xform. All rotated objects will have to be re-placed after doing this though, but it will be your best option if you want things to come out of max in the right way. Best to keep a what-you-see-is-what-you-get aproach.

I will follow your steps tonight, see what comes up.

Oh and I forgot to mention it before, but your tiles really look awesome. Lowest possible polycount, very little texture use. Thumbs up! This can be very usefull for people if they like to experience and experiment with 3ds max.
User avatar
C2_Scientist on Sat Mar 10, 2012 10:58 am
Post
Perhaps the corrupt object doesn't even exist anymore in the second version of the ZIP file, but let me know.

Thanks for the compliment about the blocks. :) Saving polygons adds up since they are going to be used a lot.

I've scaled down the objects now, but haven't got around to resetting the Xforms yet and fixing the scene just yet. I think I should be able to set up the custom units in a way that lets me work with similar looking units as before the scaling (even though I am in fact using the correct Carma scale)

Meanwhile, I found this:

http://paulneale.com/scripts/resetXform ... tXform.htm

I'll have to see if this is of any help, or if it makes any difference at all.

EDIT:

In fact, I think I found a better way still. In the utilities panel, behind the "More" button, there's a "Rescale world units". It seems to re-scale the scene while retaining all instancing and transform information of objects. After a quick test, it seems to work well, but I'll test some more.

If you wish, try these steps on a backup copy:

1) Use the "Select by name" dialog to find and delete all "Shape" objects
2) Use the same dialog to find and ungroup all "Group" objects
3) "Rescale world units", by 0.00525 (let us know what you think of this scale in the game)
4) Go to Customize/Units Setup/Custom, and enter "FL = 0.00525 Inches". The size of the smallest tiles should now be 128x128 FL in the grid.
5) Select all remaining objects, and "convert to editable poly". This step removes the instancing.
6) Export and try in-game.
User avatar
Harmalarm on Mon Mar 12, 2012 7:57 am
Post
Ok, performed your tests

The "Rescale world units" didn't work for me. It did rescale the world units, but all the objects kept having the same size, so they were all clamped together it seemed. I manually re-scaled with your values.

After removing the shape objects, and ungrouping the group objects, the scene exported without problem!

It also seems all objects are correct. I couldn't find any holes, missing collision or anything of the likes.

Also, the chosen scale seems accurate. Is it a real life scale? I always use the eagle.3ds from toxic ragers as a scale reference for my models.
User avatar
C2_Scientist on Mon Mar 12, 2012 7:23 pm
Post
Well I tried a few adjustments to scaling until it looked about right in the game, so I ended up with 0.525%. The streets seem to be ok, but the smaller buildings still look a bit too large, I think.

But as for our different results, I'm a bit confused now. :) There must be something I'm doing in a different way, so I recorded two videos of the exact steps I use, and what they result in:

http://www.youtube.com/watch?v=zzzfR7hy19U
http://www.youtube.com/watch?v=kUOeotttdew

When you said everything exported and worked ok ingame with no collision errors and gaps, were the models also properly instanced? What about the "&" prefix?
User avatar
Harmalarm on Mon Mar 12, 2012 8:10 pm
Post
ok, I uploaded the eventual max file I work with

http://harmsollie.nl/files/MaxBlocks_harmalarm.zip

What I did to get this file:

1. rescale using your second method with value 0.525 (the second youtube)
2. reset xform and convert to editable poly afterwards.
3. re-place the tree model, based on your positions using object replacer (because the original trees had their xform reset, so they lost their rotation and transform values)
4. random rotate and scale the trees again
5. rename some instanced models with the & prefix
6. export models and txt and test

trees still collide, while being rotated and slightly scaled! Other objects also seem to be fine ingame ==> proof of concept succesfull!

without reset Xform, the trees gave a collision error, or in other words, I could drive straight through them. This is why I think it is best to work with actual carma scaled objects. I think the scale has to be within a 10% range of the objects original scale to still work properly.

I don't know why the rescale world units doesn't work the same way over here. It does change the world scale but doesn't scale the objects themselves, so they all get clumped together...

Was this helpfull?
User avatar
C2_Scientist on Tue Mar 13, 2012 9:17 am
Post
Ah, my bad. I was under the impression that you had everything working without resetting the Xforms, since you hadn't mentioned it lately.

Well, apparently there's no way around it, so reset and rebuild it is. :)

EDIT:

Ok, after resetting the blocks and partially rebuilding the scene, I wasn't seeing much difference: white cubes ingame if I didn't use the "&", and false instancing if I did. But I may have found out what's going on.

The problem could lie in the object names. Since I've created size variations of otherwise similar blocks, I've also named them in a slightly different way, such as adding a "2x3" suffix to the object name.

Either the script or the game looks at these numerical suffixes, and considers them duplicates of a single block type. It then uses that single block type for the instancing, and discards the blocks with size variations.

For example, I selected a 3x8 lane piece and its instances in Max, and renamed them as &A01, &A02, &A03, etc. Now they were properly instanced and present in the world, and could be driven on. Also, Plaything's model registry showed all its duplicates as a single model: "&A", as it should be.

Next I'll look more into this to ensure that all transform information stays intact, and see what kind of problems scaling creates.
User avatar
Harmalarm on Tue Mar 13, 2012 2:50 pm
Post
Ah yes, the naming was something I wanted to mention but forgot to. Perhaps it is best to end all naming with the underscore, for instance; "&tree_" This way, when you copy it, the numbers will increase after the underscore, and things will stay organised. You can do the same for grid objects, e.g.; "&lane3x8_"... you get the idea.

Also I don't think the game automatically detects instances based on the numbers at the end. It would surprise me if it did. The only way I was able to instance objects was by using the "&" prefix.

In fact, the whole reason why your export gave you the untextured boxes instead of the textured 3d models is a mistery to me... I will have another look at my code tonight. Perhaps there is still something going on with the way I treat 3ds max's instanced models...

What you said about the 3x8 lane piece complies with my test with the trees. The model was only registered once, while there were 20 or more actors using it.
User avatar
C2_Scientist on Tue Mar 13, 2012 5:32 pm
Post
The renaming seems to have fixed things. And scaled blocks are indeed too unreliable, so I have to avoid scaling, unless we manage to find out something that fixes it.

Quote:
Also I don't think the game automatically detects instances based on the numbers at the end. It would surprise me if it did. The only way I was able to instance objects was by using the "&" prefix.


What I meant was this: suppose I have "&Sidewalk1x1", "&Sidewalk1x8" and "&Sidewalk1x16". The script/game may interpret this as: "This model is named "&Sidewalk1x", and there are three duplicates of it: #1, #8 and #16." Then it takes the "&Sidewalk1x1" model, and makes instances of this model only.

This would explain why I previously saw only the shortest blocks of each type instanced around the scene.

So you were correct when you suggested to have an underscore just before the numbering. In fact, I had already started doing that using a hyphen (-), but decided to replace them with _ in case your script already uses hyphen for something. :)
User avatar
C2_Scientist on Tue Mar 20, 2012 4:19 pm
Post
It's not dead yet! :)

I've updated the package again - this time it also includes the exported track in playable format. Even though I've been a bit busy with other things, there is some progress, mostly new decorations. Fortunately I haven't seen major problems for a long time, so it has been smooth sailing in that regard.

http://c2s.toshiba-3.com/DLoads/MaxBlocks.zip

This one can be extracted to the main C2 directory.

I'm liking how I can quickly test out the new changes in the game using the script. :) Although it perhaps could still be made slightly faster, if I knew how to write a script to automate the "find+delete shapes" and "find+ungroup groups" processes, which have to be done every time. And while at it, maybe proceed to export to a predefined target file as well (C2/Data/Races/Trackname/Trackname.SDF).

I also like the fact that I can create and export BBox coordinates directly in Max. YUM. It's very fast to setup new noncars now. :)

EDIT:

Harm, the script doesn't seem to be handling object linking correctly yet? I was trying to make traffic light color plane model a child of the main traffic light model (using "link to object" in Max), but it seems this information won't carry over the export. Currently, if you nudge the traffic light noncar in the game, its light plane won't move with it.
User avatar
Harmalarm on Tue Mar 20, 2012 8:05 pm
Post
Wow you really did an amazing job on expanding the models! The map is well playable. I really dig the round trees and the noncars you placed around.

I did notice some smoothing group oddities on the parking garage models? Is this intentional? If I where you I would simply use some auto-smooth on these models, making the poly's more hardedged. ;)

Oh and did you try to use the 'full lit trick' there? Don't forget, powerups always need the '&' AND the '£' prefix. ;)

Another note; the frame-rate is becoming a bit choppy on my shitty laptop. This is probably because of the amount of objects, and not so much the polycount itself. (which is well optimized!) You might want to experiment a bit with this (check the difference between the current setup and a setup where the whole base of the track is one big object?) I think the basic rule is, the more objects you have, the more draw calls are needed, the slower the framerate... You might end up wanting to make bigger combined objects, but again, this should be tested I guess.

About the use of groups, and the hierarchy export error: This is now on my to-do list. I actually thought the groups where already incorporated, but I must have broken something down the line. Same goes for the hierarchy. Oh and about the predefined export file you were talking about. The script remembers the last used directory doesn't it?

Maybe it is best to say that if you have issues or requests in general regarding the scriptpack, you can always post them in the script-pack topic. That way I can collect all the desires/fixes in one topic.

Actually, this track is starting to become a great example of a great track setup! Have you thought of a direction you want to take with this track design itself, gameplaywise? You now have a nice set of models but will there be a specific goal to it other than providing a tileset?
User avatar
C2_Scientist on Tue Mar 20, 2012 9:18 pm
Post
Yeah, I'll probably have to do something about the parking garage smoothing, it doesn't look totally 'clean' currently. But I'm not sure if 100% hard edges is the way to go, it may look a bit boring. :)

You mentioned drawcalls... this too is a bit optimizing related. Hard edges = vertex splits = increased transform cost, and the transform cost and fill cost of meshes should be balanced. I don't know how to estimate either of these, but since most of my meshes are very low-poly, I'm thinking the fill cost is the bottleneck. I could be wrong though, not too long ago I wasn't even aware of the two terms. If you are more knowledgeable, I'm always willing to learn more. :)

"More simple blocks" vs "Fewer complex blocks" is something I've occasionally though about too. I'll do the test of merging everything into a single object (and optimize it), and see how the performance changes.

Quote:
Oh and did you try to use the 'full lit trick' there? Don't forget, powerups always need the '&' AND the '£' prefix. ;)


The plane with the textures is named "&£150001.ACT" in Max, and its in-game counterpart is fully lit and collectable. But I agree that the textures in the noncars aren't fully bright. Perhaps there are duplicate materials for some reason, explaining the differences in brightness.

Quote:
The script remembers the last used directory doesn't it?


Yes, it does. Actually, forget what I said. The point of it was to save me a few clicks every single time I want to export. It's probably not worth taking the time to script it, especially if you're planning changes to the way the script currently handles group objects. :)

I'll keep expanding the track with new locations (I have a few in mind), and see how it goes.

EDIT:

By the way, are the opponent/drone path tools implemented yet? I tried to use the opponent path tool on a spline, but received an error.
User avatar
Harmalarm on Tue Mar 20, 2012 9:39 pm
Post
Quote:
By the way, are the opponent/drone path tools implemented yet? I tried to use the opponent path tool on a spline, but received an error.


Yes they are. Are you using the latest full pack?

picking a spline with it should make it red as a check. When exporting the TXT file using the main track setup rollout, your track txt will include the opponent path.

Download

If so, can you tell me when the error occurred and what it said? (screenshot maybe of the error appointed in the maxscript editor dialog if it gives you this?)
User avatar
C2_Scientist on Tue Mar 20, 2012 10:30 pm
Post
I re-installed the script, and it works now. After a quick test, it looks like it recognizes intersections as well. :)

Does the material ID setting of segments control anything currently? (Sorry if this has already been documented somewhere)
User avatar
Harmalarm on Tue Mar 20, 2012 11:03 pm
Post
It does recognize intersections. :D It basically assumes a main loop and then also adds alternative paths to the main path. And no, the material id's of the spline sections don't do a thing currently. Perhaps we can use it to define the type of path now that you mention this... --> added to my to-do list :D
User avatar
C2_Scientist on Tue Mar 20, 2012 11:18 pm
Post
Maybe IDs 1-3 for the few different path types, and then IDs 4+ could (somehow) control some other setting, eg section speed limit or section width?

EDIT 1:

There were some duplicate materials in the exported files. Plaything asked me to locate some multimaterial textures that were introduced by importing some of my older noncars, and it also wanted me to locate some cryptic material called 'subname'.

I went to Max for some material cleanup, and did the following:

1) Material editor/Utilities/Condense material slots
2) Material editor/Utilities/Clean multimaterial

Some submaterials were now removed, and upon opening the track, Max no longer asks me to locate some older textures that aren't even used in the scene. Track looks the same both in Max and in game. However, Plaything now keeps asking for that 'subname' material forever, so that track can't be opened. Any ideas? :)

EDIT 2:

Optimizing links:

http://wiki.polycount.com/Framerate%20O ... ion%20Tips
http://www.froyok.fr/blog/2011-11-modul ... d-drawcall

More links are welcome too, especially if they contain useful and applicable tips and information for this particular project/concept. :)


Last edited by C2_Scientist on Wed Mar 21, 2012 11:11 am, edited 1 time in total.
Pages:  1, 2, 3, 4  >>



Extra information
It is currently Mon Oct 15, 2018 3:00 pm,

Please Register a username.
In total there are 2 users online :: 0 registered, 0 hidden and 2 guests
Users browsing this forum: No registered users and 2 guests
Moderators: coffeycup, Toshiba-3

Powered by phpBB :: Hosted by n3wton :: Molested by goats
CWA Links
Facebook