Hi rolin.

OK, DON"T PANIC!

Rescaling, changes everything, so the first thing to look at is concave elements. Because when you change sizes, some round up, and others round down, in and out too, so you need to look very carefully. I'll bet you have at least two elements, [a mirror of each other] causing the trouble.

I normally these days build in half profile, and then mirror the sides, then join them together. Working that way you half the chances for errors, and don't have to map the second side.

I'm sure you'll find the offending elements and put the right.

no I'm quite sure this is not the problem bc:

I just have triangles
I've doublechecked that everything is ok again concerning the aligning

but

I have no created new (better) bulkhead elements and now it does work.. WHY the other (unscaled) model does work with the bad bulkhead elements is confusing non the less

man I have no idea why I'm still working on this : )

Hi Rolin.

I ask myself the same thing, almost everyday. But, I guess the old lady keeps throwing up new challenges all the time, and just when you think you know it all, there is always something else to add to the knowledge base.

Hello Rollin,

since the node positions are integers, any rescaling will cause a distortion on all elements when the values are rounded off. In the worst case an element may no longer sit in the right position compared to the other elements and the previous BSP tree may no longer be correct.
It's adviced to recalculate the r/s after rescaling or make sure that the node positions are in the same relative position as compared to the node positions of the original model.
This is quite a timeconsuming undertaking but necessary if you do not wish to compromise the shape of the model. The more complex the model, the more severe these distortions can become, some very small elements may even completely disappear when their node positions will be calculated to be in exactly the same spot because of rounding off. Increasing the size is less problematic then decreasing, also because of the minimal node distance you can use in EAW, an element using minimal node distance allready, will completely disappear when only one node will occupy the same spot as another in an element.
Also after a rescale the normals need to be recalculated since the node distance from the centre has changed.

VonBeerhofen

vb: thx for dropping in, jea thats what I've read in the loooooooong thread gibbon posted earlyer.

but I'm very sure this is an 3dz-studio problem .. not related to max bc max uses intern a way more detailed unit setting then what I finally read out. (though you can never be sure so I always check alignment again)

so to make it clear again.. I'm NOT working with 3dz-studio of any version or modification


So I'm always happy for every kind of help but general tips are normally more helpful then program specific ones



btw: is it important or does it have any influence in which direction the bulkhead elements point (normal) ?
EDIT: and the size ?

Hi Rolin.

The bulkheads normally cut the model in the vertical plane, but sometimes you'll need one in the horizontal plane on rare occasions.

Think of a ship, with it's watertight compartments, and you won't go far wrong.

you don't need to build in a full shape bulkhead, a 4 node flat rectangle is more than enough to get a correct cut in the RS.

If your going to add a hard point, you need firstly to add an element which covers the position where the joint will take place.

Joining things like wings need very large cutting element, which cover all of the side of the fuselage. To this element you piggyback the hard point. Once you have finished the model these large elements can be deleted, leaving only the hard point to use the RS and normals.

ok then I'm not doing something wrong.. thx again gibbon !!

I'll be off now for a while until I'm able to calculate the rs in max (or at least build an check-rs-button)
I simply don't have time and nerves to waste it with endless trial and error

Thx so far.. you was a really great help!

Hi rolin.

I hope you get this going, because it might be a way for others who use max to build models for EAW. I'm not a fan of 3ds, because I don't understand how it works to well, but if you get your converter working, you can teach me all the new tricks.

Hi, Colonel,
Well, if 3dzCalc don't work for ya', it don't work for ya'. Sorry to hear that. There doesn't seem to be much (any?) support for the program here, so I guess it doesn't work for a lot of folks. It almost makes me wonder if Gunship! handles the RS differently than EAW. Extremely unlikely, imho, but I suppose I can't entirely discount the possibility.

Not to put too fine a point on it, but I DID state that 3dzCalc can create flawed sequences. It's been my experience that such bad sequences are often relatively easy to correct manually in the 3dz.txt file. It ain't always easy-- but more often than not it's very little trouble. Occasionally (and infuriatingly) no amount of tweaking the RS will help because, as you correctly pointed out, 3dzCalc will supply a sequence even if it's impossible for a given model to have a working one. That's the most frustrating part about using the program for me.

While 3dzCalc definitely has its flaws, I don't think that it's entirely useless.

Here's an example. I don't know whether you'll consider it trivial or not. The first 2 pics are from 3dzStudio, and the 3rd and 4th pics are of the model in GS:









Spare me the Freudian interpretation of the shapes in the model, please.

There are 252 elements in the .3dz. All triangles. There are no bulkheads, no duplicated polys, no Piggybacks, and no Nulls. As it is, the wireframe cannot be processed by Gurney's RScalc. I used 3dzCalc (Root box blank, Options 1,1,1,1) and got a working RS the first time. There was no need to manually edit the sequence at all.

You may argue that had I built the model piece-meal with bulkheads and ran RScalc at various stages that I would've eventually got an RS-compliant model. That's likely true. Far be it from me to criticize that approach to building .3dzs. There're no worries about RScalc fobbing off a bum sequence on you like 3dzCalc can do at times, and you never have to get your hands dirty in the RS sector of the 3dz.txt file.

Sometimes, though, it's a whole hell of a lot easier and quicker to build a complete model and deal with the sequence after the fact.

Es muy interesante para mis proyectos de lo que ustedes estan hablando.
Lamentablemente no logro interpretar algunas cosas correctamente debido a que no hablo ingles, solo castellano.

El problema que ustedes hablan es el que se produce cuando un elemento posterior se superpone con un elemento que esta visualmente mas cerca?
ejemplo, dentro de un 3dz "W.3dz", hay un tablero sobre el ubicamos un instrumento, pero al probarlo al eaw el tablero se ve pero tapa al instrumento, es eso de lo que estan hablando?
----------------------------------------------------------------------------------------------------

It is very interesting for my projects of what you are speaking.
Regrettably I am not able to interpret some things correctly because I don't speak English, single Castilian.

The problem that you speak the one that takes place is when a later element is superimposed with an element that this visually but close?
is example, inside a 3dz "W.3dz", a board on the we locate an instrument, but when proving it to the eaw the board you do leave but does it cover to the instrument, is that of what you are speaking?