New Shape View Program Coming ..

[Snowman]

Light editing is pretty much complete. I must say it's much faster doing it visually than back and forth in notepad. I will describe each feature step-by-step below. Note that any editing has to be done in editing mode. This keeps from accidental edits while using as a viewer!

Light List:

Light List is what the name implies a list of loaded lights that can be clicked on and highlights that particular light for editing. Lights are usually close together and the shine is usually a much bigger plane than what it implies by shine alone. This will allow you to jump to that light by name. This is also one way that cloning works by right click. It's worth nothing that only lights with their respective brightness will highlight. So, for high beam editing you need high beams on!

lightlist.jpg

By clicking on a light in the list, or clicking the light directly it will now be highlighted orange.

selection.jpg

Double clicking on a light, or double clicking inside of the Light List will bring up that lights properties in Light Editor. Things like light color, azimuth, direction, headlight and unit conditions update in real time. Also if model is moved via gizmo, or move tool it updates in real time as well. Any changes at any time can be reverted to default by clicking reset in the Light Editor window before saving. Selecting any light by clicking on it updates the Light Editor window for that light.

All of these fields are hopefully idiot proof, allowing for parameters allowed for that setting. Yes, I'm aware hierarchy appears twice. These fields are not saved to file until YOU save the file! Reminder to save upon loading new shape, opening and exit works as well.

You can also delete lights and of course their section will be deleted from .eng/.wag file and number of lights updated. Color selection works in real time as well as opacity.

color.jpg
Scale is a feature as well using the menu, or by shortcut "S". It works much like SketchUp. Scale also is also editable in the bottom right corner box.

scale.jpg
Movement at the moment of objects can be done with move tool via shortcut "M" or menu. It allows for 10mm movement of objects by arrow keys and shift+arrow will slow to 1mm.

The gizmo tool currently works for no non-sense movement in any axis and rotation. It works well, but works best in conjunction with move tool at the moment. It's available via menu, or shortcut "G". Gizmo isn't the prettiest thing, but it gets the job done. Changes to X,Y,Z can also be done in the bottom status bar in the right corner. The status bar window can be hidden and isn't seen outside of Editor mode.

gizmo.jpg

Clone works as they name suggests via menu or shortcut ctrl+d, or right clicking on object and selecting clone. This will clone that light and it's properties with the only addition is "Clone" added to the name of the light. Remember no changes are made to your files until you save. All "changes" are in memory until you save.

clone.jpg Some care was made to make sure edits will work in MSTS. I probably forgot a ton of stuff, but you get the idea. If you're not sure, ask me! If you don't see it then suggest it.

* The only thing left to do is cloning multiple selected objects.
* Work on lighting to look more like Open Rails.
* Test, test and test some more..

[EldoradoRailroad]

This is of great interest...as the light section can be very pesky to do when a model is either new or modified. shifted..shifted positions, etc. Ditto for exhaust "tricks", which is beyond the scope of your program.

It has been some time, but as I recall ORMG, not sure about plain OR, can now have multiple light textures, not just the "canned" one. Somewhere on Elvas Tower there is a post that indicates that multiple/different light textures are now possible. Having access to that in this new shape viewer would be a big plus. I am not sure if OR respects all the values for azimuth, at least not in my experiments for pitch, roll, and yaw.

I suppose the ultimate "undo" for screw ups is to not save your work in edit mode. Do you have other plans/ideas for "undo"?

I think that what you have written here is that adding and deleting lights will be possible in the viewer.

Great stuff...

Steve

[Snowman]

I am not sure if OR respects all the values for azimuth, at least not in my experiments for pitch, roll, and yaw.

From my testing and this makes MSTS happy is that azimuth can be set to max 180 180 180, or -180 -180 -180. Anything beyond that and MSTS complains. That's how I judged the limits for OR as it typically ignores mistakes which is good most of the time, but if you cant figure out why your light wont rotate the way you want and OR ain't complaining...

It has been some time, but as I recall ORMG, not sure about plain OR, can now have multiple light textures, not just the "canned" one. Somewhere on Elvas Tower there is a post that indicates that multiple/different light textures are now possible. Having access to that in this new shape viewer would be a big plus.

In terms of per light light glow that is already implemented as you can see in the screenshot. This allows for per light having it's own glow as noted here.

glow.jpg

Ditto for exhaust "tricks", which is beyond the scope of your program.

I'm open to any ideas as anything that will simplify editing, why not? Exhaust smoke editing is on my mind but match OR may or may not be hard, I'd have to see, or look at their code. Never say never.

I suppose the ultimate "undo" for screw ups is to not save your work in edit mode. Do you have other plans/ideas for "undo"?

No, but if anyone has any I'm all ears.

I think that what you have written here is that adding and deleting lights will be possible in the viewer.

That's correct. It's already "working" and so far so good. It will delete that light block and update the number of lights in the .eng/.wag file.

The only thing I need to address is while in move mode, it needs to update what axis it moves on based on users camera in viewport.

Some other ideas I have and are close to getting to them are below as I need to button up other things for a few days before I think about much else.

* animations and the ability to animate.
* ability to move texture on model. send texture to editor of choice and reload on model.
* ability to model which would include MSTS/OR properties built for "simplicity" as much as possible.
* save shapes out as obj, 3ds or dae.

[yellowdog]

Lots of great features being discussed here. This definitely sounds more like an editor than a viewer. With that in mind, maybe an “undo“ option would be for the program to generate a backup copy of the original file whenever saved edits are made?

[Snowman]

Lots of great features being discussed here. This definitely sounds more like an editor than a viewer. With that in mind, maybe an “undo“ option would be for the program to generate a backup copy of the original file whenever saved edits are made?

It's certainly turned into an editor at this point. Currently the editor saves the modified file as a .bak when final save is made. No other changes to file are made until you save the file, so simple undo for edits should work along with backing up of original file upon save. Of course this will overwrite if you make multiple saves of the same file.

[EldoradoRailroad]

or...
.1eng
.2eng
.3eng
.
..
...
.Neng

where is "N" is the defined number of backups, before a rollover, in a ".config" type file?

Steve

[EldoradoRailroad]

Some other ideas I have and are close to getting to them are below as I need to button up other things for a few days before I think about much else.

* animations and the ability to animate.
* ability to move texture on model. send texture to editor of choice and reload on model.
* ability to model which would include MSTS/OR properties built for "simplicity" as much as possible.
* save shapes out as obj, 3ds or dae.

I would say animations is at the top of the list of needs, very important! Countless times wire frame view with animations in Gausden's program has saved the bacon for me!

Thanks,
Steve

[Snowman]

Now supporting reading of .wag and .eng files and includes .inc files for loads etc. I don't know if I mentioned before but Open Rails FreightAnimStatic and Offset are read. Copy of text inside of Hierarchy window now supported.

inc.jpg

I would say animations is at the top of the list of needs, very important! Countless times wire frame view with animations in Gausden's program has saved the bacon for me!

I didn't know Shape Viewer had a wire frame view.

[Snowman]

Support for export to .obj, dae and .3ds complete. Any loaded shape can be exported to .obj, .3ds and .dae along with texture preservation (.tga) ready for any modeling program.

model03.jpg model01.jpg model02.jpg

[EldoradoRailroad]

Snowman wrote:
"I didn't know Shape Viewer had a wire frame view."


Pressing the "tab" key shunts the model to the wire frame view in Gausden's program. As well in the wire frame mode, highlighting an entry in the hierarchy list also highlights the respective model part in wire frame mode. If there are any doubts please check the Gausden's Shape Viewer for what I have mentioned here.

Hopefully this is not a big ask!

Thanks,
Steve

[Snowman]

If there are any doubts please check the Gausden's Shape Viewer for what I have mentioned here.

I couldn't get it working, but who'd thought the help menu would have the answer. 😆

wireframe.jpg

[EldoradoRailroad]

I couldn't get it working, but who'd thought the help menu would have the answer. 😆

Ohh....MY BAD! Must be getting old when I confuse "tab" for "backspace".....sorry for the wild goose chase..but at least...I was correct about wire frame mode!

Too many fingers in too many pies, and I should always "have time" to post..I did not yesterday, it was a work day.

Thanks,
Steve

[pschlik]

I'm curious how editing lights will play with include files. I have all my lighting setups hyper-compartmentalized, to the point where the set of lights is in an .inc file separate from the .eng (multiple engines use the same set of lights), then the properties of some of the lights are in a second .inc file (multiple sets of lights use a few of the same individual lights), while the color of those lights is defined in a third different .inc file (multiple individual lights use the same color and other graphical properties), none of these being the .eng file, of course. I would prefer if editing things preserved the structure (so changing the color would change the color in the color .inc file) but I can imagine that quickly becomes extremely awkward to keep track of with all kinds of ambiguous situations.

[Snowman]

I'm curious how editing lights will play with include files. I have all my lighting setups hyper-compartmentalized, to the point where the set of lights is in an .inc file separate from the .eng (multiple engines use the same set of lights), then the properties of some of the lights are in a second .inc file (multiple sets of lights use a few of the same individual lights), while the color of those lights is defined in a third different .inc file (multiple individual lights use the same color and other graphical properties), none of these being the .eng file, of course. I would prefer if editing things preserved the structure (so changing the color would change the color in the color .inc file) but I can imagine that quickly becomes extremely awkward to keep track of with all kinds of ambiguous situations.

This isn't implemented, only reading of shapes at the moment. If I understand correctly, you simply paste your lights from your loco into the include file, but I'd still like to have an example of this as I'm pretty sure my models just have loads and nothing like lights being mentioned here. If someone can point me in the direction of a full implementation of lights in an include file that would be great. I assume the same works for tender lights other than folder structure?

Implementation is straight forward as the only difference if I'm correct about how lights work in include files is after reading the include file it would display just the same in the Light Editor window, but edits would have to know to save to include file and not eng, or wag file no big issue there either. Once I have this information, I'll implement preserving folder structure and saving lights to where they were opened.

[pschlik]

This isn't implemented, only reading of shapes at the moment. If I understand correctly, you simply paste your lights from your loco into the include file, but I'd still like to have an example of this as I'm pretty sure my models just have loads and nothing like lights being mentioned here. If someone can point me in the direction of a full implementation of lights in an include file that would be great. I assume the same works for tender lights other than folder structure?

Implementation is straight forward as the only difference if I'm correct about how lights work in include files is after reading the include file it would display just the same in the Light Editor window, but edits would have to know to save to include file and not eng, or wag file no big issue there either. Once I have this information, I'll implement preserving folder structure and saving lights to where they were opened.

All my physics mods will have absurd setups for lights in include files. Full mods are on the Train Sim Community website (I have yet to make an update that I'd be comfortable uploading here) and some one-off releases like the Santa Fe GP39-2 have my physics and lighting in them.