SSU Development Thread (2.0 to 3.0)

[Urwumpe]

I started a new thread for development discussions, the old one was already a long one and really unstructured. We should be quicker in starting new threads for special features in the future.

So, feel free to discuss here, how the development of SSU should go on from 2.0 to 3.0. Please don't use the thread for asking us how to use SSU. This is the wrong place. Don't ask what we can do for you, ask what you can do for SSU here.

Enjoy the development!


------------------------------

As one of the first questions to the team in the next iteration - can we please reduce the number of sticky threads in the subforum? Its far too much I think, especially I get some toothache, that the LC39 and Centaur Prime development threads are made sticky - if we would do that for EVERY feature in development of SSU, we would have 4 pages of sticky. Some less enthusiasm, ok?

What about having non-sticky development threads (reasonable necroposting allowed) and a single sticky "SSU Showroom" thread for the new meshes or other screenshots showing new eye candy?

------------------------------

And does using UMMU/OrbiterSound in SSU violate the GPL 2.0? I feel like it, maybe we should make using these libraries in SSU optional for builds and no longer mandatory.

 

[SiameseCat]

And does using UMMU/OrbiterSound in SSU violate the GPL 2.0? I feel like it, maybe we should make using these libraries in SSU optional for builds and no longer mandatory.

I don't think using OrbiterSound violates the GPL any more than using Orbiter does. I don't see any reason to make OrbiterSound optional.

On a totally unrelated note, is anyone able to help fix the animations to work with the new mesh?

 

[DaveS]

I don't think using OrbiterSound violates the GPL any more than using Orbiter does. I don't see any reason to make OrbiterSound optional.

On a totally unrelated note, is anyone able to help fix the animations to work with the new mesh?

What is the problems with the animations?

 

[SiameseCat]

What is the problems with the animations?

All the reference positions need to be fixed to match the new meshes.

 

[DaveS]

All the reference positions need to be fixed to match the new meshes.

OK. Could you list the animations that needs their ref points updated?

 

[SiameseCat]

I think all the shuttle animations (air data probes, payload bay doors, landing gear, etc.) need to be updated.

 

[Urwumpe]

I think all the shuttle animations (air data probes, payload bay doors, landing gear, etc.) need to be updated.

I think we should always have one manual for each mesh for the project, that contains all important information how the mesh should be used.

This way, we can also always be sure to use the proper coordinates.

 

[SiameseCat]

I think we should always have one manual for each mesh for the project, that contains all important information how the mesh should be used.

This way, we can also always be sure to use the proper coordinates.

What would we put in the manual? I don't see any point to this. As far as the animations are concerned, the only way to get the coordinates is the open the mesh in something like MeshWizard and see where the rotation point is. It's not something you can put in a manual.

 

[Urwumpe]

What would we put in the manual? I don't see any point to this. As far as the animations are concerned, the only way to get the coordinates is the open the mesh in something like MeshWizard and see where the rotation point is. It's not something you can put in a manual.

Which groups are used for which animation
Which reference points
Which axis or operand vector

Yes, we can also always open up MeshWizard after the meshes are made and we need to correct something. But I think it would be more effective to have this data written down while the meshes are made and by who makes the mesh.

 

[SiameseCat]

Which groups are used for which animation
Which reference points
Which axis or operand vector

Yes, we can also always open up MeshWizard after the meshes are made and we need to correct something. But I think it would be more effective to have this data written down while the meshes are made and by who makes the mesh.

I don't make meshes, so I could be wrong, but I don't think it's easier to get the animation data when the mesh is being created instead of when the animations are defined. Also, for a lot of meshes we don't implement all the animations immediately. For something like the VC, it would be a lot of extra work for the mesh creator to document every possible animation.

 

[Donamy]

How many switches?:leaving:

 

[DaveS]

I'm having a bit of hard time understanding the animations of the PLBD pushrod/clamp/pullrods. The ref numbers for clamps/pullrods are where each component connects to each other when in the retracted configuration?

 

[Donamy]

Do you know how long, it took me to figure that out. :facepalm:

 

[SiameseCat]

I'm having a bit of hard time understanding the animations of the PLBD pushrod/clamp/pullrods. The ref numbers for clamps/pullrods are where each component connects to each other when in the retracted configuration?

I think so, but I'm not certain. If you're having a hard time with the PLBD animations, I can take a look at it later.

 

[DaveS]

I think so, but I'm not certain. If you're having a hard time with the PLBD animations, I can take a look at it later.

There's some weird stuff going on when it comes to the coordinates for the orbiter. The ones in orbiter do not agree with the ones I get from the model in AC3D. This makes correcting the ref numbers a trial&error effort with alot of error.

 

[SiameseCat]

Can you post the numbers you're getting from AC3D? I'll see if I can figure out what's going on; the meshes are getting shifted around a bit as a result of the CG updating, but I don't think this affects the animations.

 

[DaveS]

Can you post the numbers you're getting from AC3D? I'll see if I can figure out what's going on; the meshes are getting shifted around a bit as a result of the CG updating, but I don't think this affects the animations.

I'll check in what I got and I'll post examples how things are supposed to look.

 

[Donamy]

For one thing, if you get one right, the rest are the same.

 

[DaveS]

I'll check in what I got and I'll post examples how things are supposed to look.

This is now done.

The figures from AC3D for the various elements:

FWD radiators: 2.71, -0.84, 0
RMS SY: -2.63, -0.47, 7.12
RMS SP: -2.63, -0.17, 7.12
RMS EP: -2.63, -0.23, 0.76
RMS WP: -2.63, -0.23, 6.3
RMS WY: -2.63, -0.23, 6.79
RMS WR: -2.63, -0.23, 7.06
RMS EE: -2.63, -0.23, 8.0
RMS EE light: -2.01, 0.23, 7.46

---------- Post added at 03:22 AM ---------- Previous post was at 03:21 AM ----------

For one thing, if you get one right, the rest are the same.

Yes, but nothing from AC3D agrees with Orbiter which is causing alot of headaches right now.

 

[SiameseCat]

This is now done.

The figures from AC3D for the various elements:

FWD radiators: 2.71, -0.84, 0
RMS SY: -2.63, -0.47, 7.12
RMS SP: -2.63, -0.17, 7.12
RMS EP: -2.63, -0.23, 0.76
RMS WP: -2.63, -0.23, 6.3
RMS WY: -2.63, -0.23, 6.79
RMS WR: -2.63, -0.23, 7.06
RMS EE: -2.63, -0.23, 8.0
RMS EE light: -2.01, 0.23, 7.46

---------- Post added at 03:22 AM ---------- Previous post was at 03:21 AM ----------


Yes, but nothing from AC3D agrees with Orbiter which is causing alot of headaches right now.

The RMS values I'm getting (from MeshWizard) are

SY = -2.466, -0.6535, 7.123
SP = -2.632, -0.173, 7.124
EP = -2.581, -0.3285, 0.757
WP = -2.632, -0.173, -6.293
WY = -2.632, -0.173, -6.734
EE = -2.632, -0.173, -8.0

These work fairly well.

The AC3D values you posted don't work (the SY, WY and WR joints). Just from looking at the numbers, the SP, WP, WY and WR joints should all have the same X/Y values, and only different Z values. I'm not sure if AC3D is giving incorrect values or if you're looking at the wrong point on the mesh; the reference point needs to be at the center of the joint.