3ds Max - Think Tank

[QMan 0]

I have a question- the Gmax to 3ds Max tutorial- does that work the other way around?? Like for 3ds Max to Gmax?? Because I'm not sure if the BATforMAX works with 3ds Max 2008- unless someone else has it and can give me a heads-up if it does...

[Jasoncw 11,840]

It does.

Also, I think that 3ds Max can export into a format that Gmax can easily open. Gmax has a lot of exporting functions removed, which is where the problem originated.

[autoVino 26]

goto file->export->and save as a 3ds format.  Texture corrdinates can be preserved, but you might have to retexture your model in gmax (in gmax do import and the file you saved).

I don't see why bat4max shouldn't work though.  I'm not using 2008 though.  Have you tried to run it in 3ds 2008?

edit:.... oh okay, I didn't reply first...

[SimFox 802]

Just a s Jason told MAX2008 works fine with BAT, in fact it works with it better then say MAX9. That is with well know limitation of night Windows - this method of night lighting shouldn't be used with any Max past v7.

And, as AutoVino said it can export 3ds files. Just make sure that the materials applied to your models are standard ones.

[JakeMD 107]

What do you mean by standard materials?

[SimFox 802]

Exactly that - Standard materials. That is a name of the type of material, besides it MAX2008 had the whole host of different type of materials straight out of box (Arch&Design, MentlalRay, Physical Pheng, etc) and more in any additional plugins were installed (V-Ray, Final Render etc...) This is important cause Standard is the same type that is used in GMAX. So that you will be able to transfer them.

[autoVino 26]

Posted this in sc4devotion, some crude shadow theory in the game vs lighting rig, maybe it will have some use here too...

As far as I understand from experimenting with shadows, you are correct.  Shadows, I think (and am 90% sure), come from the fsh alpha files that are perpendicular to the current view.  The alpha is distorted and skewed so that it lands on the ground.  There are some exemplar files in the simcity DAT that can edit/distort this and edit the shadow, which is a mask on the ground that makes the ground look darker.  I have seen the ability to lengthen the shadows and to shorten them by moving the sun, but not to change their direction... which is logical based on how they are derived.

Moving a sun, in the real world, will change how a shadow looks like off of a building, not just by simple distortions such as skewness and rotation, but it will change the shape.  This is because as the sun moves, some parts of the building open up and become more passable for the light and some close up for the light (tell me if this doesn't make sense, I'll try to explain better).  This requires full 3d information to calculate how the light will pass and not pass through the model.  The game cannot do that.  It is limited to a simple alpha map and it cannot accurately change/distort the shadows to match the building.  Here is a crude example:

How the game will calculate shadows, approx. (top view)

How the lighting rig will calculate shadows, approx. (top view)

How the game will calculate shadows, skewing and rotating them, to attempt to match the lighting rig shadow, approx (top view)

Because you don't have true 3d information in the s3d file (only a limited lod with 4 views slapped on), no amount of skewing or rotating will be able to correctly show the shadows.  And this is only 90% sure, because that is how sure I am that the shadows are calculated this way (using the fsh alpha files from an adjacent view).  Hope that makes sense for my skepticism in fixing the shadow problem in the game (thought the game directly).

But a fix for your problem, Sim Fox, would just to not let the fsh files extend beyond the lod (or below the lod), like you said, this is what is most likely causing your problem.

btw, thank god for the new spell checker :-p

quote>

[Jasoncw 11,840]

Do you guys think it's time for all of us to change our rigs to match the game's shadow angle?

Has anyone already figured out what angles the lights need to be?

People using Gmax can also edit their rigs as well, which is good.

[SimFox 802]

Well it is a possiblity... problem is that the angle of the Game sun isn't terribly beneficial to the buildings.

45 degrees is (or at least was) considered standard for architectural drawinsas it creates shadoews that best define the shape. Game sun will create very long shadows eating away and the details in stead of revealing them. Situation will be particularly bad with Default rig as it's low res shadowmapos will drown the facade with any pertruding features in a messy blob of "shadow".

But that is just a thought... Some experimentation would be needed. The angle of game sun is in one of those properties. It memory serves me right it is something like 68 degrees.

Still I think it would be better to find the property that is responcible fro the skew factor in game. It must be there, I don't think it has been somehow hardwared into exe or something like that when all the other properties are there to tinker with.

On the other hand WHY and HOW on earth game with such an obvious graphical glitch ahs been released and never fixed in numerous updates?

[JakeMD 107]

Anyone know of a good mental ray tutorial for max 8?

[patriots_1228 51]

Yea, Autovino wrote one himself.

somthing like "Making good window textures", but it contains a bunch of other useful mental ray tutorials.

[autoVino 26]

Originally posted by: SimFox Well it is a possiblity... problem is that the angle of the Game sun isn't terribly beneficial to the buildings.

45 degrees is (or at least was) considered standard for architectural drawinsas it creates shadoews that best define the shape. Game sun will create very long shadows eating away and the details in stead of revealing them. Situation will be particularly bad with Default rig as it's low res shadowmapos will drown the facade with any pertruding features in a messy blob of "shadow".

But that is just a thought... Some experimentation would be needed. The angle of game sun is in one of those properties. It memory serves me right it is something like 68 degrees.

Still I think it would be better to find the property that is responcible fro the skew factor in game. It must be there, I don't think it has been somehow hardwared into exe or something like that when all the other properties are there to tinker with.

On the other hand WHY and HOW on earth game with such an obvious graphical glitch ahs been released and never fixed in numerous updates?quote>

 

I don't think that the game has any skew factor, because the making of the shadows does not requier any skew so it probably never was encoded.

Let me explain by replicating (how I think the game does it) how the game creates its building shadows:

It starts with the alpha files of the view adjacent (to the left, so rotating the model counter clockwise).  It takes that file and rotates it 90 degreese then scales it hor. by aout 140% and ver. by about 70%.  Then it slaps the shadow on the model.  Here are some illustrations:

(the first model represents the shadows with the standard lighting rig, this is why they don't align correctly)

Very simple to do and probably very simple to code.  No skew requiered.  Changing the suns declenation/right ascension only changes how the game rotates and then scales the alpha file.  

Plus there is a problem with skewness (as I explained in a few posts above), the shadow simply won't be accurate if skewed.  It may be accurate for a simple box building, but anything more elaborate will be inaccurate (but most people probably won't even catch that the shadow is off by a tiny bit).

The point here is that having the shadows formed perpendicular to the camera is the simplest and most accurate way to "fake" the shadows with the limited amount of information given.

[SimFox 802]

auto:

interesting theory and reasoning!! I'll take a close look at it when I get back from moscow...

[Jasoncw 11,840]

That seems totally spot on.  Unfortunately it means that we're stuck with this problem. 

I don't think Maxis cared because most of their buildings did not have cantilevers or modeled plazas in the way that our BATs have had.

[Jasoncw 11,840]

Unfortunately it seems that there is a problem with anti aliasing.  I used AutoVino's method posted below (the mat tab in the Reader):

Flags:

x Alpha Test x Framebuffer Blending

x Depth Test x Texturing

x Backface Culling

Alpha Func: Always

Depth Func: Less Than or Equal

Src Blend: Source Alpha

Dest Blend: One Minus Source Alpha

The problem can be seen in my screen shot above.  The areas being eaten are those that are covered up by the LOD of another AA BAT.

- The Pylons are eating 211 West Fort Street (the tall modern building)

- The Pylons don't seem to be eating each other.

- Benjamin Pump is not eating the Maxis tree props.

- 211 West Fort Street is not eating the base of the wind plant.

- 211 West Fort Street is eating the animated part of the wind plant.

Does anyone have any insights into this?  It would be a shame to have to stop using AA.

Also, while I'm here, everyone who wrote long tutorials needs to go back and check to see if they are still intact.  When the site was attacked a few weeks ago, long posts were truncated.  If the posts are from 2007 or earlier I might be able to retrieve/fix them for you if you ask.

[SimFox 802]

Hm...

I'm completely lost on this AA issue...

Where is that tutorial? could someone direct me?

another thing... you should take a look at your alphas... it might be so that they aren't exactly black, that may happens with Sun/Sky lighting setup. If that is a case you can make a separate export just for alphas (even with ALL lights off) and then substitute those alphas into actual export folder.

Also you may set the AA value for say alpha a bit higher (in max itself)

[Jasoncw 11,840]

That could be it, the environment background is grey. I'll try that out report back (the pylon takes two minutes to export, lol).

It's autovino's tutorial, but it's not functioning correctly because of the site attack from a few weeks ago.

[SimFox 802]

that's it!

If it gray it would be taken as white (because of the compression used in FSHs) so just make alpha export and substitute those

[Jasoncw 11,840]

ok, well, I re exported with the black background, and tested it in game, and the problem is still there, though right now I only have one BAT that is AA with a black matte.

Can someone who has a collection of their own AA BATs (with black mattes) test to see if they are having the same problem? It might not be obvious since most LODs are pretty tight, and because most buildings are not AA.

[autoVino 26]

Could AA in Bats be setting dependent?  Maybe higher settings would allow for AA in bats and lower settings would not.  Could it also be dependant on whether the rendering engine is set to hardware or software?  Could it also be dependent on the videocard/video settings/capabilities?

Maybe AA works on props, but will cut off buildings...

Just speculations...

[Jasoncw 11,840]

ok, so I worked some more on the AA problem.  Here is AutoVino's thread about it, and later down, xannepan reports the same problem I'm having.

I think that this is just one of those problems that is inherent in the properties. 

The problem only seems to happen when it's next to other AA buildings, which isn't very many.  I think I might include both an AA .SC4Model and a non-AA .SC4Model in the upload, with a disclaimer.  None of the stuff I did caused the game to crash, so I think it's ok.  Then in the future I guess I won't AA unless it really needs it. 

[BurroDiablo 222]

I saw you mention that mental ray in 3DSMAX 2009 has some problems with Bat... I just got 3DSMAX 2009, I haven't exported anything yet so I haven't noticed, but I'm glad your on the case since i'm sure you'll be able to fix it

[SimFox 802]

This thread had been started as a forum for the exchange of ideas and practical solutions for the aging Bat4Maxv2, we all use and love.

For it's time it has been something of a revolution, but as years have been passing problems with it were accumulating. Bugs, incompatibility of some features with newer versions of 3ds MAX, luck of support for new objects (photometric lights for instance), bugs of original development (the infamous instanced lights problem etc, etc, etc...

It all calls for some solution that hasn't been forthcoming so far.

I've decided to make my own little contribution and now present you first little update - version 2.1.

Changes done don't really warrant the whole new number version but none the less they are of some significance. here is a list of changes:

Installation of the BAT

---

For some reason the original was supposed to take over the PlugCFG declaration in 3dsmax.ini. At the time this, for some reason, had been considerate necessary or, may be, just not important enough to be bothered with. But later one with development of 3ds Max and also new exporting techniques in exporting models coupled with the obscure location of 3dsmax.ini file in last 3 versions of the Max made this arrangement highly undesirable.

This update provides a solution - when doing fresh install of the BAT4Max it is no longer necessary to touch or even know of 3dsmax.ini. Just replace CPTB2Startup.ms in original distribution of the Bat4Max v.2 with one in my update.

Changes in workings of the BAT.

---

New CPBuildingMill.ms script that handles all the export procedures has been updated to work correctly with ALL types of lights present in all the current and most likely future versions of 3ds MAX, including those from 3rd party renderers (like V-ray, for instance)

Another change is that it no longer requires to make copies of nitelites. you can instance them as much as you wish - big saving on editing time - it is enough to adjust brightness or color of one instance and all other shall follow changes. Also instances are far more merciful on the memory.

Best way to take advantage of this new version is to do clan install of it. If you have Bat4Max already installed in your system you may still consider to do an update  - full (replacing all 3 scripts) or partial  - by replacing only CPBuildingMill.ms.

In case of full update you  would need to revert to the original version of 3dsmax.ini file. Or edit it back by changing the PlugCFG line to point to the original location. This is advisable as Bat taking it over may seriously interfere worth proper functioning of the MAX.

Anyway here are the files. If you have problems or questions just ask.

[SimFox 802]

^^

El Burro...

Well I don't share your optimism...

I've tried everything I could think of to no avail. I hope for some help from others but so far haven't heard anything... Problem is that this issue is so specific that is on no interest to larger 3d community.

Actually one issue I've raised with Autodesk about problems with orthographic projections in Max9 had been addressed and fixed in Max 2009. But about this current problem I doubt there will be similar response. Since it ONLY limited to BAT. At least, so far, I ahven't been able to replicate it anywhere else. It just minor interpretation of script code, I guess...

The key to all now is to get some basic understanding how output/render window is sized in BAT. If that will be solved Scripts could be greatly simplified and streamlined.

[Jasoncw 11,840]

First of all, thanks for BAT4MAX V2.1!  The installation changes are a big plus, and it will be nice to be able to use instanced lights.  And I'm sure as BAT4MAX becomes more streamlined the errors will start fading away.

If you want to I can try to get this in the Modds & Downloads section, or whatever else you want me to do to spread the word.

The little problem with Ukraina and few other models is that in a zeal to give a test drive to Max2009 I'm done some modeling there. ther are few very neat features... but as it happens Mental Ray there has some problem with BAT. Namely it frames the output window a bit wrong way. As a result FSHs do not match the LOD shell... I'm a bit at a loss what to do. My knowledge of either MR (and particulary somme neances of changes introduced in Version 3,6 or MaxScript - to compensate for them isn't quite there. But AS you who use Max know it isn't backward compatible. I head though about some script that supposedly allow such compatibility but I don't quite know where to get it...

So I'm now thinking what to do.

Ideally some solution for the new MR issue should be found. Cause it not it may spell the big problem for the future... And I'm trying to decipher the Scripts.quote>

This would be very convoluted, and would only be used to rescue what you have already made, but you could export with something other than Mental Ray, to produce bitmaps that are properly aligned, and then you could Photoshop Mental Ray renders on top of them (using the non-mental ray renders to help you line it up correctly).  You could also just export it as a .3DS and import it to a lower version of Max.  But I know these aren't the suggestions that you're looking for. 

There might also be a way to shift the .FSH files into proper position, but it doesn't look like there are options for that in the Reader.

[SimFox 802]

Jason, Thanx, I should think how to package this update for the Download section...

About the Ukraina, and the host of other models... Of Course that would be possible (for instance align them through Alphas made with Scanline of a dark scene - so it would be very quick) but for he building size of Ukraina Or RT that would be mammoth task aligning those.

It couldn't be done in iReader because it isn't just matter of shifting FSHs. Problem is that they are cut in the wrong places. so they all would have to be reassembled into the single image of Zoom/Rotation, manually realigned to the proper renders and then re-sliced again

Fortunately I've found quite a miraculous way that allows sort of time travel - ability to beam the stuff to the older versions of max! It is really like beaming in Star Trek. The entire scene is getting disassembled and coded as a set of Scripts with MaxScript and then reassembled in the older version of Max!!! The system is absolutely ingenious work of art by Bobo - the guru of Max scripting and called BFF (Bobo File Format or Back from Five - since it was written by Borislav back in the day when Max5 was brand new!! It works perfectly today too! Particularly great part of it is that it is absolutely version independent! and despite been created 5 years ago works with latest version perfectly!

So I have been able to recover all the additions I have done in Max2009 back to Max2008. So I'll be exporting them from Max2008. In these instances there wasn't really NEED for Max2009's MR 3.6, but for RT, or particularly base of it there might be... I plan to use some MR Proxies for foliage. Otherwise it's 20 million polygons might be a problem in terms of Max Database handling capacity... So I may do the lower part in Max2009.

I just wonder how could we attract someone like Bobo to our cause!?! I can't even imagine what a wonderful tools he would help us to create!

But I with my limited skill and understanding will continue to look into the scripts. I have very strong feeling that 80% of it is redundant, remnants of the original GMAX scripted plugin simply left there. I remember there was talk of doing full featured Plug-in for MAx that would bypass then GMAX stage altogether, So may be that explain all those functions left in scripts. Because otherwise all is needed is rather simple rendering and slicing script nothing more. The only complicated part in it would be setting output window right.

I'll be stripping scripts from those "excesses" one at the time trying to determine minimun needed for export to work and then "seek professional help", so to say...

[Jasoncw 11,840]

ah! Great news!

Yeah, it would be amazing to find someone as talented as that, or just someone with a solid knowledge of it. Unfortunately we're in our own little backwaters. But we have managed to get some people like that, and today we have the Reader, among the other great programs.

Also, I was wondering, if there's any way in 3ds Max to have objects be "masks".  So let's say I have my ground plane, and I change some setting on it, and now everything that is behind the ground plane gets masked out of the alpha mask.

[autoVino 26]

@Jasoncw: the mask idea is interesting.  I have been thinking about something similar (actually, reverse of your masking idea), but haven't experimented yet.  

Maybe make the whole scene invisible to the camera except a single mask object.  This mask object will be transparent with ior of 1, so pretty much like surrounding air.  The key here is that transparent objects can "reveal" invisible objects (objects that are unset to visible to camera) through thier refraction/internal reflection.

As a result, one can make a type of 3ds max lod that won't toll on the polycount of the ingame lod.  So by making a tight fit "maks lod" (which is the transparent object) around your model (which will be hidden) one can eliminate offending underground objects from the render (what gets put onto the fsh files).

Like I said I haven't experimented at all with this and I don't know how this will toll on the render time (if it will at all) or even if it will work, but just another speculation/idea.

[Jasoncw 11,840]

That's a really clever idea AutoVino, and I think it would probably work (I don't see why it wouldn't). But yeah, it seems like the render times would increase a lot. It might be more practical to manually edit the alpha masks manually.

[autoVino 26]

Maybe if you only need to edit a few of the alpha files, and only for the first few zooms (5,4 and 3).  But if it's a big buidling with a large underground section it may be tedious.  All depends on the size of the underground and the quality your going for.

I did some testing.  Normal render:

Render with a mask (all objects are hidden from the camera except the mask object)

So the render (naturally) is longer with the mask method, by about 20% longer.  Some things I noticed while watching these renders are that the percent of uncalculated fg points in the render visualization during fg calculation is high for the masked render, meaning accuracy is at an expense, but the fg calculation time for the masked render was almost twice as fast as the normal render.  The intensive render part was the actual meat of the render, where an image comes up.

So render time isn't too bad, but accuracy is lost on the render.  In order to get the same accuracy, render time will be even higher.  My guess would be by 50%, which is okay on 3 minute renders, but on hour long renders that can add up to be very very significant.