SSU Development Thread (2.0 to 3.0)

[Urwumpe]

Yes, there's a reason and that reason is that for now SSU is not stable and hard to get. We primarily operate through SourceForge in a raw source code environment.

That's no reason for wild editing in the "production grade" sources. You can create branches for experimenting in the future.

 

[DaveS]

That's no reason for wild editing in the "production grade" sources. You can create branches for experimenting in the future.

Which I did, then someone decided they were good enough for merging back into the trunk.

 

[Urwumpe]

Which I did, then someone decided they were good enough for merging back into the trunk.

I can't remember that anybody approved the many edits and new errors that crept in later.

 

[Donamy]

I believe the coding issues were caused by the reckless changing of the meshes.

 

[DaveS]

I can't remember that anybody approved the many edits and new errors that crept in later.

Check the logs for any mentions of 2-1 new meshes or something like that. That was thy name of the branch that held the new meshes and code for them.

---------- Post added at 05:05 PM ---------- Previous post was at 05:03 PM ----------

I believe the coding issues were caused by the reckless changing of the meshes.

That is not correct by my memory. The coding problems and delays have been there since day one.

 

[Donamy]

So, do we go back to the original mesh and re-release ? The one we have now is too far gone to try and salvage.

 

[Urwumpe]

Check the logs for any mentions of 2-1 new meshes or something like that. That was thy name of the branch that held the new meshes and code for them.

Yes - and I remember that we did not see the broken normals and other stuff in them at that point. You simply kept on working on them afterwards.

 

[Donamy]

That is not correct by my memory. The coding problems and delays have been there since day one.

If you use the original mesh with the newer code, the animations are not working.

 

[GLS]

So, if the 2.1 branch mesh (rev1601) didn't have problems (besides the size issue) can't we resize it? Or at least try? Even if it's not perfect "on the inside", I think it would be better that going back to last century's mesh, that would require lots of code to be rewritten. Then we could release the new version, and at the same time start a branch, with top priority, to create a super-efficient, all-neat-numbers-inside and drop-dead-gorgeous orbiter mesh. At the same time the "graphics department" is doing that the "coding department" would do the mission editor (whatever it's called) and that would be the core of the subsequent release.

My :2cents:

 

[Donamy]

Who has the 1601 mesh ?

 

[Urwumpe]

Who has the 1601 mesh ?

We can get it from Subversion. You can get any file of SSU of any revision number, as long as it has been committed to the repository.

 

[Donamy]

We can get it from Subversion. You can get any file of SSU of any revision number, as long as it has been committed to the repository.

I've been unable to do that for quite awhile. If someone could send it to me, I'll take a look at it.

 

[DaveS]

History of Orbiter.msh, all revisions available for download: https://sourceforge.net/p/shuttleultra/code/1814/log/?path=/trunk/Meshes/SSU/Orbiter.msh

 

[Urwumpe]

I've been unable to do that for quite awhile. If someone could send it to me, I'll take a look at it.

Do you use TortoiseSVN? Its pretty easy to use.

 

[GLS]

just navigate http://sourceforge.net/p/shuttleultra/code/1601/tree/

 

[DaveS]

Do you use TortoiseSVN? Its pretty easy to use.

http://www.orbiter-forum.com/showthread.php?t=30336

 

[Donamy]

History of Orbiter.msh, all revisions available for download: https://sourceforge.net/p/shuttleultra/code/1814/log/?path=/trunk/Meshes/SSU/Orbiter.msh

revision 1463 to 1601, jumped from 10 mbto 15 mb, are you kidding me ?

 

[DaveS]

revision 1463 to 1601, jumped from 10 mbto 15 mb, are you kidding me ?

Plenty of changes, for example addition of the FRCS module and thrusters. Kittable aft PLB radiator panels (3 and 4), accurate platforms for PLB cameras B and C. Accurate elevon and seal panels.

That's just some of the changes that added stuff. The biggest contributor was the new PLBD interior and the T0 umbilical panels.

 

[Donamy]

Do you have anything before the resizing ? Another reason for the increase in size is the fact you didn't delete faces that don't show.

---------- Post added at 05:02 PM ---------- Previous post was at 04:43 PM ----------

I am unable to load any of the orbiter meshes into my 3D program. I can only use what I have, so that's where it stands for me.

 

[DaveS]

Do you have anything before the resizing ? Another reason for the increase in size is the fact you didn't delete faces that don't show.

---------- Post added at 05:02 PM ---------- Previous post was at 04:43 PM ----------

I am unable to load any of the orbiter meshes into my 3D program. I can only use what I have, so that's where it stands for me.

Try revision 1655, loads for me. And I just did an export of it, minus the new PLBD interior and the aft T0 umbilical panels. File size went from 16 289 kB to 10 815 kB, proving what I wrote earlier.

And the reason why the VC mesh won't load into AC3D is because there's alot of junk vertices. Unlike the msh import/export script for 3DSMAX/GMAX the msh import/export script for AC3D doesn't complain about junk vertices/faces and other problems. It just ships them out and doesn't care. So when you try to import a junked mesh file, the result is a hard crash.

In order to retrieve the positions for the various switches, I had to import the VC mesh into GMAX first and use its Remove Isolated Vertices function and everything and then re-export to msh. Then it imported into AC3D with no issues whatsoever.