Calm down Ray.

Don't bust a blood vessel for a piggyback!

I don't know why you think I'm agitated. I haven't resorted to any name calling or insults or anything that would indicate I was about to burst a blood vessel.

I've made a number of cogent, sincere statements as an experienced 3dz user.

I do note that it's always a trivial matter when it's the other guy's concern.

Hi Rotton50,

I am sorry if it has got you upset. That was not my intention.

All I was saying is that in my opinion Piggyback elements are a big no-no and tried to justify why I have that belief.

Things are always written in stone, but not based purely on what some peoples (my) beliefs are. The writing into stone is done by the up-grader of a program, as he/she will be doing only the work that is of interest to him/her.

As I said earlier, I don't have the time or the inclination at the moment to work on the project, so what I say will have no impact with any person that does choose to extend the 3dz Studio.

Regards Syddy

Oh okay, that makes sense I am just trusting the existing normal values in the models for now. This seems to be a reasonable assumption to make, except for elements that are parts of moving parts - I think they have correct normals, but the constant "D" part is wrong. Is this something that has been observed in EAW? Is this related to:

Are the constant "D" parts of the normals calculated as if the moving part's origin was (0, 0, 0) or something?

As for the argument:

I think that sydbod's approach sounds possible - I think I could make a model that way - but I can imagine an easier way...

I think the below would address this:

I was going to say the same thing myself! In terms of getting a warning when the RS tree can't be generated, I guess we might define "failure" as the tree generation running for more than a few seconds. The warning should probably indicate what element you added to trigger the RS tree generation failure, just in case you've added another element since then, but I gather the user interface probably doesn't enable you to add elements very quickly?

I can't imagine it would be very hard to add this to the current 3DZ Studio - you can just save a temporary .3dz file after every element addition and call the RS tree generator in the background. 3DZ Studio can kill the RS tree generator if it runs for too long and delete any huge log files it may have generated.

Also:

So a piggyback can't be a separate element referencing the same nodes?

How is this done, just by highlighting any element for which there is some other element with the same shape and node locations? Or is there explicit tracking of the piggybacking somewhere?

I'm not sure that that is a good reason to dislike VB. I, on the other hand, used it for years before I learned some better languages, so I think I am fully qualified to dislike it I like the sound of this other tool which runs under Linux - it can't possibly be written in VB But seriously, no offence intended to the VB programmers out there - it does have its place, and there are plenty of things that are easy to do in VB that are much harder to do in C!

One last, kind of off-topic, thing: would "vertex" be a better term than "node"? I have used the term "vertex" in my documentation for F-15 III, knowing that the EAW documentation used the term "node". Or is it like this: a "house" is not a "home" until someone lives there, and a "node" is not a "vertex" until it actually forms an extent of a line or polygon? I just think "node" is a bit too generic; one normally talks about a binary tree (such as the RS tree) consisting of a set of "nodes". Perhaps nobody will care to debate this with me

Regards,
David

Syddy,

I repeat, I am not upset, so no apology necessary.

This medium is lousy for debates like this. We lose so much by not being able to hear the other person's vocal inflections.

This is a hobby for me, not a vocation.




David,

1 - It would be a huge improvement in the R/S calculator if it would tell us which element was causing the problem. Right now you build a few elements and then test the model to see if it's still R/S compliant and so forth.

2 - On the "elements" pop up work screen there is a box labeled "Piggybacks". If there are piggybacks to that element you can scroll through them by clicking the up and down arrow next to the box. In Will's version the box turns bright green if there are any piggybacks. In Gurney's version the box stays gray.

G'day,



My understanding is that, except in a few trivial cases, the RS calculator is often NOT going to be able to tell you which element is causing the problem, except if it tries removing one element at a time. I guess the point is that it is often not one particular element, but a combination of elements that causes the problem. That said, I think the solution where the RS calculator is run automatically after you add each element would help here: you'll be told which element you added that caused the problem, you can try removing it right away to see if it fixes it, and if it does then you can think about what the fix is.

Maybe the RS calculator could allow you to supply the element number of the most-recently-added element to it and it could treat that element as new and unproven. Then, if at some point in trying to partition the elements, it fails because it would have to cut that new element in two, instead of just trying another partitioning scheme, it can fail and tell you which element intersects with your new element so you can consider splitting one of them. Still, I'm not that confident that such a scheme would help much - it might just tell you that every element you add is "bad" because the very first element you inserted was in a bad place.

Perhaps there is no way to make an editor and RS generator that are so smart that you don't have to understand how the BSP scheme works, but perhaps if the editor tells you right away when you've added an element that prevents an RS tree being generated, it will help people to learn. You might get lots of questions on the forum saying "why can't I add this element to this model" but perhaps when the experts explain which other element is causing the problem, people will learn from that? You can only hope!

Regards,
David

Hi David,

You are correct, we (the EAW community) tend to use the term "Node" rather than "Vertex" mainly because very few of us have had any formal training in anything to do with modeling and we tended to use the terminology that was used in documentation left behind by our forefathers. We maybe ???? should be using "Vertex" but old ingrained habits are hard to break. Maybe "Vertex is not the correct term either as we can have the dots or the Node/Vertex/Whatever-it-is standing in free space all by itself. I suspect a Vertex is just a Vertex if it is part of a polygon corner ..... or am I wrong there?

I believe we have the same sort of miss-naming going on with the RS Generator. The way we us it, it is just a BSP(RS) finder, and not a generator. The true BSP(RS) generators will actually produce cuts within existing polygons to enable the creation of working BSP(RS) sequences even if there is no current solution. Needless to say both the rendering engines for both games are limited to 255 nodes/vertices/whatever-it-ises and 255 Polygons so allowing the automatic cutting of polygons is not a viable solution.

Maybe we are fortunate in that we all appear to know what the other person actually means rather than says.

Regards Syddy

Just one more thing I would like to highlight about BSP(RS) sequences.
It is possible to create a model and as one is in the process of creating it, it is possible to get a situation where a working BSP(RS) sequence becomes impossible. As one continues adding to the model, a working BSP(RS) sequence all of a sudden becomes possible again.
EG:


If one were to create the wing and the tail fin first as in that picture, and then try to create a working BSP(RS) sequence, it would fail. Then one adds in a bulkhead from the body of the model, and all of a sudden a working BSP(RS) is possible again.

One may want to think twice about partially building a model and concluding that a construction path is impossible, just by testing for BSP(RS) compliance of a partially built part of a model.

Regards Syddy

Hi doshea.

All of the moving parts of a 3dz have to have to be built in the deployed position. The RS and Normals have to then be generated from the zero point of the model. At this stage you have to ad the offset codes to the Normals and Nodes, and reposition the parts of the model, back to the correct positions. This is because the Offset is normally the centre point of the folding part of the model, from the zero point, and when you add this Offset to the existing Nodes, it has the effect of moving the entire section, like a wheel, way out of position. This s a very complicated topic to try and describe, but I'm sure you get the idea.

Piggyback elements can be a duplicated element which is coded to switch on/off, like an engine panel, damaged and undamaged, or an element which is added to fill a new position on a model. Piggyback are often used to split old elements, to refine the shape of a model. Often you need to add more than one piggyback to cover this new element, so the new element appears to work correctly.

In EAW, Vertex = Points, and recently Nodes has been used. Either is fine by me.

ok I have to ask some questions too


first.. Gurney's rs_calculator: if the calculationen takes up more than a few secounds or say half a minute, does this mean the rs_tree is not calculatable?

is it important which starting Element is choosen when using rs_calculator? or does the program finds a good one by itself?

and: does onybody has succesfully used will's 3dz calc ?
(http://members.fortunecity.com/whb11/GunshipTool/Gunship.htm)
I'm not able to calculate a working rs-tree even from simple testmodels (easy enough that I can think them through myself and Gurney's rs calculator needs just a sec)