trevor Geschrieben 28. Dezember 2016 Geschrieben 28. Dezember 2016 (bearbeitet) Hopefully this is something you are correcting in version 4...however we really need to be consistent with the origin location and original orientation on ALL models in the catalog. Looking at the two images here your can see that this particular steam loco starts out pointing east while the diesel is pointing south. Moreover, the Steam loco has its origin located well forward of its linear centre point..... Also, When it comes to rolling stock..it would also be prudent to have the Z-Origin at track level. Despite the fact they stand on the same track, the two cars shown in this image have different Z coordinates because they have different heights. To maintain the integrity and conformity of user generated models, the model creation and importing tool should really do this kind of lateral and rotational adjustment automatically. (possibly with the aid of a few manual options on the import screen) Of course, none of that is terribly important if you are just a plug-and-play layout painter, however, if you are trying to calculate spacial orientation and relative coordinates in plug-ins etc it becomes a major nightmare..... (Also..from a correctness point of view.. notice the bumpers are not at the same height on those two wagons....) Bearbeitet 28. Dezember 2016 von trevor
trevor Geschrieben 28. Dezember 2016 Autor Geschrieben 28. Dezember 2016 While I am on the topic... something is just plain wrong with the scaling of the last three cars on this train. According to the properties, they are all scaled to N-Scale, but the last three are simply too small, the wheels don't touch the tracks and the bumpers are all too low.
Henry Geschrieben 28. Dezember 2016 Geschrieben 28. Dezember 2016 hi Trevor, have in mind that the 3 cars were delivered before 2010 - old stuff - scaling was only done by refering the track width. it is just a toy to be run with the first program versions. Take it as a simple toy - not as a model. Regards, Henry
trevor Geschrieben 28. Dezember 2016 Autor Geschrieben 28. Dezember 2016 (bearbeitet) 1 hour ago, Henry said: have in mind that the 3 cars were delivered before 2010 - old stuff - scaling was only done by refering the track width. Yes, I figured it was probably something like that. Though, with my minor attempts to create my own models, scaling on the import seems to be a "difficult" concept to control. (I added a waitress to my private set from sketchup a couple of weeks back.... she started out being about 5miles tall LMAO.) I think some additions to the importer are warranted to allow you to set the initial size / origin / rotation AFTER the 3DS model file is read. In particular, for rolling stock... identifying the wheel distance ought to be sufficient for setting the scale. However, generally as a user contribution style application, there ought to be some guidelines and moderator(s) verified rules for folks to follow to improve consistency. Bearbeitet 28. Dezember 2016 von trevor
BahnLand Geschrieben 28. Dezember 2016 Geschrieben 28. Dezember 2016 Hallo Trevor, vor 6 Stunden schrieb trevor: Hopefully this is something you are correcting in version 4...however we really need to be consistent with the origin location and original orientation on ALL models in the catalog. Looking at the two images here your can see that this particular steam loco starts out pointing east while the diesel is pointing south. Scanning for vehicles in the online catalog, you find most of them oriented to the x-direction (to the right, see in the mid of the picture above). But there are a lot of vehicles, which are oriented to the y-direction (backwards, see the right part of the picture above). Most of them are from me (Eurofima, RAe TEE II, freight wagons of DWV, RoLa), but there are also some railcars from Quackster and all american vehicles from Feuerfighter initially oriented to this direction. The reason, why I had decided for the y-direction, was a program error in the program 3D-Eisenbahnplaner (the predecessor of the 3d-TrainStudio) nearly 3 years ago, where the boogies of multi-axle vehicles in the inclination could not could not be adapted to the track profile when the vehicle was oriented to the x-direction (see the picture below). But with orientation to the y-direction, I didn't have this problem (see the next picture with the Eurifima wagon). So, (nearly) all my vehicles got the y-direction, which I have not corrected till now because of compatibility (when changing the orientation, all affected vehicles already placed on a layout suddenly get rotated by 90°). Till now, I didn't see any problem with different initial vehicle orientations because they will be automatically correctly adjusted to the track when placing onto it. But what is really the correct orientation? When placing a single track to the base plate, it will be initially oriented to the y-direction (see the left part of the 1st picture above). This disagrees in fact to the "normal" vehicle orientation to the x-direction. Because the error descibed above is corrected already for a long time, it is for me no problem to select another initial orientation for new vehicles from me. But what is now the correct orientation? I don't know it because of the detected conflict between the default orientations of the track and most of the vehicles. What is the opinion of Neo to this conflict? Many greetings BahnLand
trevor Geschrieben 29. Dezember 2016 Autor Geschrieben 29. Dezember 2016 17 hours ago, BahnLand said: But what is really the correct orientation? I guess that's debatable... but my point really is the importer/application should take care of all that behind the scenes. No matter how the original designers 3d model was configured by each users model design preferences, the model library should remain consistent. I came upon the issue when I tried to write some code to figure out which carriages were attached to which locomotives by calculating the end locations of each rolling-stock object and finding the chains that way. The code works great when they are all originally oriented the same way and have their origins in the center.. but otherwise the math doesn't work. Now the only way I can figure to do it is to add some major extra code to pull in the library object as a new instance, surround it with planes, use the distance finder commands to measure its extents, delete all that, and then figure out conversion variables to apply to the math. Repeating for every object. But even then I would need to make some major assumptions.. e.g. the longest size = track length, and which end is the front would be a downright guess. I am really wondering how NEO does this in his code. Either he has access to a LOT more model object properties we can't access, or his layout start-up math must be extremely, and overly, complicated... 17 hours ago, BahnLand said: which I have not corrected till now because of compatibility (when changing the orientation, all affected vehicles already placed on a layout suddenly get rotated by 90°). Yes that is a significant issue, and was why I mentioned it needs to be corrected, if it is, in the next release, where, presumably, opening V3 models will cause significant data manipulation to the design file anyway, so doing the math at that time to adjust the current positions to the corrected library models is doable.
Neo Geschrieben 29. Dezember 2016 Geschrieben 29. Dezember 2016 Hi, vor 24 Minuten schrieb trevor: I am really wondering how NEO does this in his code. Either he has access to a LOT more model object properties we can't access, or his layout start-up math must be extremely, and overly, complicated... the content creator defines the orientation of the vehicle during import, see the track vehicle editor (menu Catalog - 3D models - New - Track vehicle). The math to rotate each vehicle back to a "default" state is just a simple quaternion rotation. For MBS a default orientation is not needed, why the content creators are not restricted to any orientation. Future versions will automatically rotate all objects so that they face towards +X, but only for visual "equality". Until now MBS does not support accessing such detailed information by the command interface, so there is currently no solution without assumptions. Kind regards, Neo
Empfohlene Beiträge
Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren
Du musst ein Benutzerkonto besitzen, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen.
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden