SSU Development Thread (2.0 to 3.0)

[Donamy]

My problem is, I can't import the mesh into AC3D. So little chance of me fixing it.

 

[Urwumpe]

Can't the mesh be edited in Blender?

 

[Donamy]

I don't use blender, besides the original orbiter mesh was made in AC3D.

 

[Donamy]

DaveS and I seem to have a difference of oppinion, on the way the SSU development works. We had a working mesh that I had done, which he took it upon himself to change, because in his oppinion it was too big and the dimensons were wrong, not so by my sources. Be that as it may, I think it should have been discussed here, before it was released as a build.

As it is now the new mesh has many flaws,that need to be fixed.

Anyone have any thoughts on this.

 

[GLS]

To be honest I have no clue if the mesh is the right size or not... mesh/texture work is "black magic" to me. :lol:
If there's a difference of opinion on something (as it seems), what I think should happen is the "graphics department" should gather all the data, sit down and work out a solution. Probably somebody is going to be wrong and somebody is going to be right, but that doesn't matter as everybody makes mistakes. What matters is getting the job done.

 

[DaveS]

In the interest of cooperation and team spirit, Donamy could you list what you think is wrong with the mesh?

This way a discussion can be held and everyone get their say.

 

[Donamy]

In the interest of cooperation and team spirit, Donamy could you list what you think is wrong with the mesh?

This way a discussion can be held and everyone get their say.

A better question is, why you felt the need to change my existing mesh ? Also, why was repositioning it needed. I think we should go back to the old mesh, that is not all distorted and in need of extensive remapping. The diagrams I have, are NASA documents purchased from Scott Lowther, so you can be guaranteed of their accuracy.

 

[DaveS]

A better question is, why you felt the need to change my existing mesh ?

Well, I felt the accuracy of it could be improved upon. There was alot of incorrect items and the closer I looked, the more inaccuracies I discovered. And there was no way of remedying them without a full-blown rebuild.

Yes, I rebuilt most part of the orbiter from the ground up. The only original items left is the FWD fuselage, landing gear wheels, CCTV cameras and the SSMEs. The rest was done entirely by me.

Also, why was repositioning it needed. I think we should go back to the old mesh, that is not all distorted and in need of extensive remapping.

This part is not clear. What distortions and remapping are you talking about?

The diagrams I have, are NASA documents purchased from Scott Lowther, so you can be guaranteed of their accuracy.

I got over 32 GB worth of data (schematics, photos and documentation) and I have cross-checked every bit.

 

[Donamy]

The distortions around the startracker doors are just horrible. You did a nice job on the leading edges and umbilicals, but the Orbiter looks like it has a case of the mumps. And I guess we'll have to agree to disagree on the dimension issues.

 

[Urwumpe]

The distortions seem to be just the normals, should be possible to fix. And yes, they are a no-go for release. If you are not fixing them, I will do that and that won't be fun for all of us.

The dimension issues are simple to solve: measure the damn thing. I don't give a damn about micrometres there, even millimetres are no reason for big arguments. If the dimensions are not directly from the plans, but measured from photographs, I will stay by my opinion from the last quarter of the year: Ignore them. They are very likely not more accurate than the mesh we had.

The motivation that we are wasting here for discussing the state of the meshes could also have been used for adding cue cards to the VC mesh for improved gameplay.

And DaveS: The few hundred bytes of the star tracker distortion are right now much more relevant than the 32 GB of data of your storage. Better concentrate your strength in finding the right numbers and the <½ GB of documents that we really need right now.

Nobody is disputing that you are likely the only person on this planet who knows all nuts and bolts on the Space Shuttle by name and serial number, but we have a problem to solve here.

 

[DaveS]

I wrote about the star tracker problem here: http://www.orbiter-forum.com/showthread.php?p=481042&postcount=434

So it has been a problem since Day One.

 

[Urwumpe]

I wrote about the star tracker problem here: http://www.orbiter-forum.com/showthread.php?p=481042&postcount=434

So it has been a problem since Day One.

Yes, but the suggested solution is not that well-received. For an understandable reason. Also, I think Donamy had reported it already earlier in the thread.

 

[DaveS]

Yes, but the suggested solution is not that well-received. For an understandable reason. Also, I think Donamy had reported it already earlier in the thread.

The suggested solution being "fly-as-is"? I'll see what I can about the problem.

 

[Urwumpe]

The suggested solution being "fly-as-is"? I'll see what I can about the problem.

No, it was the "redo the fuselage from scratch", which left some questions open about the "why this problem appeared in first place", since redoing the fuselage would mean a lot of effort for getting back to a state that we actually already had.

 

[DaveS]

No, it was the "redo the fuselage from scratch", which left some questions open about the "why this problem appeared in first place", since redoing the fuselage would mean a lot of effort for getting back to a state that we actually already had.

It's related to the upper fuselage surface geometry between the windshield and the FRCS module cavity. Something about it makes AC3D creating a weird smoothing problem when adding the the star tracker cavities.

 

[Urwumpe]

It's related to the upper fuselage surface geometry between the windshield and the FRCS module cavity. Something about it makes AC3D creating a weird smoothing problem when adding the the star tracker cavities.

Yes, it screws up the normals, likely because you create concave areas, which are not easily treated by every algorithm.

You have quite some options there but: why did you mess around with the star tracker cavities in first place, remember this? And why did this error creep into the trunk?

 

[DaveS]

Yes, it screws up the normals, likely because you create concave areas, which are not easily treated by every algorithm.

You have quite some options there but: why did you mess around with the star tracker cavities in first place, remember this? And why did this error creep into the trunk?

IIRC it was due to the physical size/locations of the STs. I'm investigating several solutions right now. I should have something in a couple of hours.

The original smoothing error in v2.0 crept into the trunk after some mesh work that altered the smoothing angle.

 

[Urwumpe]

IIRC it was due to the physical size/locations of the STs. I'm investigating several solutions right now. I should have something in a couple of hours.

Sounds great.

Sadly we can't really test meshes automatically, something that would be an option for most of the SSU module code, if we are willed to refactor a lot and do a lot of branch by abstraction.

 

[DaveS]

After some experimentation, I think I might have something. Early results are good but further assessments are in progress.

 

[Donamy]

The dimension issue, is over an overall length number. My source as posted above is 1458.24, DaveS's mesh has it as 1428.95. By scaling the original mesh down, all measurements were affected. Just moving the star trackers to different positions would cause distortions.