SourceShifterDocs
Development

Legacy ideas

The old pipeline ideas of SourceShifter.
Beware! There is factually incorrect information within this page!
If you do want to take some words from this page, please fact check them!

The legacy ideas of SourceShifter were the very first pipeline ideas made by T342guy in the SDD.md file. The ideas were created when the project was named Source toSource2 reimporter apon its creation, then turned into legacy ideas before the project was renamed SourceShifter.

(LEGACY IDEA) If we were to do .mdl --> .vmdl

T3: At the time of this idea's creation, I thought that FBX was the ideal format, as most of the tutorials on porting pointed to using FBX. Though I didnt realise that FBX usally would be upscaled unintentally. In extention, FBX did not carry the textures like I had assumed, since that would add an extra step into the pipeline, and adding an extra step for the end user. And extra steps for the end user is what we are trying to avoid, so it was clear that doing something else was needed. The main reason that directly porting into Source 2 format was ideal, is mainly since it is possible to compile everything into the .vmdl extention and their accomplices, being able to be drag n' dropped into and out of ModelDoc. This way, we should be able to achive our goal of no-to-low end user steps. But we still need to see reality.

In notes below this, tecnically we can translate directly to .vmdl. And yes, this would be a better option then if we were to take the .mdl --> FBX --> .vmdl route.
However, this comes with potental drawbacks. First of all, old pointers and new pointers between the 2 files may not be easily migrated with this method.
This could possibly be solved by doing the .mdl --> FBX --> .vmdl route, as then they would automatically be re-created. again, this would cause extra steps, more spots of failure, and so fourth.

Introduction to development

The development side of SourceShifter! For those contributing, this may help!