[1.9.x] NEBULA EVA Handrails Continued

[Bit Fiddler]

Back on this...   I will get some new models made, but as before I will need help with the texturing and importing them into the game.  if anybody has experience with importing a blender file into the unity engine and or experience with how the textures need to be made I am open to idea sharing.  This basic ladder rung can be extended easily to make longer "rails" just by extending the "rung" so any length of this is possible.

 

Also please comment on the mesh?  should I make it more simple to make it have less GPU overhead.  using less memory and causing less lag?  or should I make it more complex, to make it look better by adding more faces to make the curves more smooth?  Keep in mind you may end up with a large number of these on a ship if you build custom ladders, or just have a lot of hand rails on a large craft.

 

 

Spoiler

 

Edited April 16, 2017 by Bit Fiddler

[DStaal]

I'd go with simple - I either tend to have no handholds on a craft or lots and lots, so the less impact each has the better.

[Bit Fiddler]

I can easily remove the round bolt plates on the bottom, thus reducing the vertex count.  this will be a bit of a savings, but as mentioned, if you end up with a hundred of these on some large craft, that small savings can add up.

 

just need to balance looks with performance or make 2 parts, the low poly version for the over use craft and a high poly version for a craft where only 1 or 2 are used.  I am open to all ideas, just say what ever comes to mind, and we as a forum can work out what to do.

Edited April 16, 2017 by Bit Fiddler

[linuxgurugamer]

On 4/16/2017 at 2:28 PM, Bit Fiddler said:

I can easily remove the round bolt plates on the bottom, thus reducing the vertex count.  this will be a bit of a savings, but as mentioned, if you end up with a hundred of these on some large craft, that small savings can add up.

 

just need to balance looks with performance or make 2 parts, the low poly version for the over use craft and a high poly version for a craft where only 1 or 2 are used.  I am open to all ideas, just say what ever comes to mind, and we as a forum can work out what to do.

Ummm, how difficult would it be to have both? or, possibly, two selectable models?  Selectable as in having two .mu files, and a cfg which can be edited (either by hand or vi a MM cfg to select either the more detailed one or less detailed one

[TheRagingIrishman]

2 minutes ago, linuxgurugamer said:

Ummm, how difficult would it be to have both? or, possibly, two selectable models?  Selectable as in having two .mu files, and a cfg which can be edited (either by hand or vi a MM cfg to select either the more detailed one or less detailed one

That's really not hard to do. It's a one line change in a part's config. 

[linuxgurugamer]

Just now, TheRagingIrishman said:

That's really not hard to do. It's a one line change in a part's config. 

That I know, the question is about making two different models of the same thing

[TheRagingIrishman]

Just now, linuxgurugamer said:

That I know, the question is about making two different models of the same thing

Sorry, misunderstood what you were asking 

[Bit Fiddler]

2 models is easy.   I can make 2 parts one is a low poly part for large ships and another high poly part for small ships where you might want some high  detail for screen shots or what ever.  the creation of the actual 3d mesh files is not the issue.  the real problem here is that i still have no idea how to get them textured and into unity.

 

I know the best solution for this will be to reuse an existing squad texture similar to ... SXT?  I think that is the mod that does that.  basically all the 3d mesh files are told to use a texture supplied by squad so there is very little memory used for the new parts as those textures are all in memory already.  so this should not be to big of a problem.   however the actual .obj to unity conversion is where my knowledge falls apart.  it will take some research to figure this bit out, or a modder who is familiar with this process to join the team and do the conversions for us.

 

 

EDIT:

so in my research into importing the mesh into KSP I have read many conflicting instructions on which version of unity must be used.  Can anybody weigh in with a definitive answer to this?

Edited April 24, 2017 by Bit Fiddler

[cakepie]

Rather than making two versions (hi-poly and lo-poly), I'd suggest:
- basic *.mu contains only bare handrails
- second *.mu contains only embellishments

Then combine using MODEL{} nodes (instead of "mesh=") in the standard cfg file. For low poly, use MM to remove the second MODEL node.

Edited April 26, 2017 by cake>pie

[Bit Fiddler]

with this method is it possible to have the player be able to select them at will?  as in I have a huge station type of ship, and it has hundreds of ladder/handholds scattered over the surface, so I need low poly hand holds in these locations.  then at the high traffic points like the "living" areas where the hand holds are more likely to be seen the high poly version can be inserted so the objects look nicer in the areas most likely to be seen in screen shots etc.  this is the ideal setup for a mod of this nature as players may want to mix and match the 2 style of rails on one craft depending on the likelihood of a screen shot or close-up in videos.

[DStaal]

1 minute ago, Bit Fiddler said:

with this method is it possible to have the player be able to select them at will?  as in I have a huge station type of ship, and it has hundreds of ladder/handholds scattered over the surface, so I need low poly hand holds in these locations.  then at the high traffic points like the "living" areas where the hand holds are more likely to be seen the high poly version can be inserted so the objects look nicer in the areas most likely to be seen in screen shots etc.  this is the ideal setup for a mod of this nature as players may want to mix and match the 2 style of rails on one craft depending on the likelihood of a screen shot or close-up in videos.

For mix-and-match like that, probably the easier way to handle things is to just have two sets of parts - which could be done fairly easily.  (I'd have one set be just an MM clone of the other with the new models, myself.)

However - I'm not sure if it would help in the situation you describe.  Assuming KSP/Unity is moderately optimized, it's probably only loading one copy of every model being used in the current scene, and then just applying it where needed.  So it depends a bit on where the bottlenecks are in the render on whether that would reduce overall model complexity (improving performance) or increase number of models in the scene (reducing performance).

[Bit Fiddler]

well I do not have a "real" answer on this, but in my previous testing it did seem that making a large craft with hundreds of hand rails adversely affected performance.  as each handrail is an object that physics must be calculated for, and your video card must interpret and render.  it is not so much a question of how much memory is used by the loading of several parts, but rather the load on the physics system, and the work done by the actual video card to render them all.

[DStaal]

Oh, definitely more parts is more load, and simpler parts is less load - but the question is whether replacing *some* of the parts with nearly identical parts that are simpler helps or not.  You aren't reducing the part count, and you're increasing the model count (so it can't reuse processing paths as much) - while reducing the overall complexity of the ship.  So how the physics and graphics engines handle things is going to make a big difference.  (Does it create a single super-model that gets rendered?  Does it reference each part's model separately?  What optimizations have been done to parallelize things?  Does it need to keep models in video ram?  Etc...)

[Bit Fiddler]

ah I see what you are getting at now...

 

 

any way here is an example render with no texturing of the original (mid range?) model, in white.   and the higher poly model with an example of adding in more detail, in the gray color.

 

 

the basic difference is all the "cylinders" on the white are set to 16 faces, while the gray is set to 32.  with the additional detail of a bolt and the cutout for the wrench.

 

this is not the actual unity render this is just a sample in blender.  so mileage may vary once in game.

 

 

the actual 3d modeling is not a problem.  it can be done in a matter of a few hours.  the real time sink is going to be the texturing and the unity import.  so what ever is wanted for a final product should be considered now before all the work for texturing and import is done.   I am leaning toward just making them a simpler design and making 1 style, but I do not do a lot of screen shots and videos.  so i am not the best one to decide what is wanted for that.  but the actual work to make the models is quite simple so no worries what ever is decided i can do.

 

 

This shows what i am leaning toward.  just make them as simple as possible, by removing the base and all extra bits. they will still look good enough in game I would think and the functionality does not depend on the 3d model at all.  so that part is not an issue.   this view does however give you a better idea of the "quality" difference in the original 2 handrails.  as the low poly version is now in the foreground and you can more easily see the "facetation" (lol is this is even a word?)  caused by the lower poly count.

 

 

and just to put this all in perspective here is an example of a 2.5m cylinder to give a better idea of what they would look like attached to a 2.5m part

 

 

 

I would say it is @linuxgurugamer who would have the final say in this, as it is his mod.  but I am open to what ever people want.

Edited April 28, 2017 by Bit Fiddler

[Bit Fiddler]

Any input @linuxgurugamer?   what would you prefer for the style?  simple or complex or both?  once we decide on this I will continue to make the rest of the parts in the same visual style.  for various lengths of straight handrails like this, we just need to make the "handle" part longer so any length is possible.  maybe even a dynamically sized part?  and then for the curved rails we also need to decide on what hull diameters to support.

Edited May 9, 2017 by Bit Fiddler

[linuxgurugamer]

4 hours ago, Bit Fiddler said:

Any input @linuxgurugamer?   what would you prefer for the style?  simple or complex or both?  once we decide on this I will continue to make the rest of the parts in the same visual style.  for various lengths of straight handrails like this, we just need to make the "handle" part longer so any length is possible.  maybe even a dynamically sized part?  and then for the curved rails we also need to decide on what hull diameters to support.

Sorry, been busy.

If it isn't too much trouble, then both, I can then use the Part Upgrades to be able to go from one to the other.  Make the complex ones a bit thinner, would be a reason for them to be a bit lighter

Hull diameters, should be 1.25, 2.5, 3.75 and 5, and maybe 1.875(??)  Anything bigger than that can use straight ones

[Bit Fiddler]

doing some more work on this...

I am thinking maybe use Firespitter or some other method of model switching to make the parts change based on user input in the VAB.  for instance you select "Curved Hand Rail" from the part list and place it on the craft.  you can then right click on it and select the diameter slider to adjust this part to what ever diameter the part is attached to.   I would still need to make an individual model for each diameter for the model switching .dll to use, but this would also allow the parts to be switched for complexity.  as a user could select "style 1", "style 2", "style 3" etc.   this does make me have to do 3x the modeling, or more, depending on how many styles...   just an idea.   this would also be how the user selects the "length" of a basic straight hand hold like the examples I have shown here.  again every model would have to be made as there is no "procedural" aspect to this.  it is just model swapping.     but if this sounds like the path you want to take I will work this into the design as I move forward.

or alternately we could get with the procedural part guys if needed and see how to go about making them procedural.  then I would not make any of the "hand hold" bits, rather just the end caps, and the procedural portion of the mod would fill in the gaps between them.  or maybe along the lines of the fuel lines in KAS/KIS, place two end point and "connect" them, and the .dll would figure out the radius of any turns and the length of the handrail. 

I am going to press on with the non procedural assumption, but if you can find a way to work that in it is not a big deal to replace all the rungs with procedural bits, and just keep the end caps.

 

also what parts are 1.875?  I do not recognize that size, but probably just from not paying attention.  I am sure I have those parts installed, as I install most every part mod.

 

 

and another note...  the original parts the end caps were not really the end on the curved bits.  the hand hold actually extended past the endcap a bit.  did you want this styling again or should the curved bits end with the endcap like the straight bits.  or for that matter would you like the straight bits to extend past the end cap like the curved bits?

 

and a further note  what levels of symmetry do you want to support?  as in if I select radial 4 there will be 4 parts placed do I want this to close the loop on the curved bits?  or close it at R6 or R8 etc.   as the part gets bigger in diameter the larger symmetry may work better but at low diameters it will make each hand rail be rather small.  however unless you find a way to do that hand rail bit procedurally, this needs to be thought out ahead of time as I must make the models conform to this right from the start.   unless anyone has a better idea I am going to go with 4R on the 1.25 and probably 2.5, and then maybe go to R6 or R8 as the diameters get larger.  however I tend to shy away from R6 in that I would think most people will want them to be snapped to R2, R4, or R8.  I do not plan to make an R2 version however just the R4 and if they want an R2 they can place two of the R4.  any thoughts on this?    I can indeed go ahead and make a "powers of 2 set" and a "powers of 3 set"  again it is all just more modeling and parts to deal with either in separate parts or in some sort of mesh switcher like firespitter.  but with the extra R factors built into the "editor extensions" I can see someone may want to use a "powers of 3 set"

 

 

Thinking about maybe not end caps at all, but rather a central "Mount point" with the "Rungs" extending to either side..  what do you think?  I could redo the straight bits with this theme as well no problem.  this is all fluid so no worries change your mind as often as you like.

 

this example is an R4 on a 1.25m part.

Edited June 14, 2017 by Bit Fiddler

[Bit Fiddler]

@linuxgurugamer did you look at this new styling?  what do you think?

[linuxgurugamer]

Sorry, wasn't aware of the post.  You need to ping me, otherwise I might miss it.

Anyway,  the styling is very nice, I like it.

Regarding all the new work, it's entirely up to how much work you want to do.  Firespitter is fine, so are JSI Part Utilities,  and/or the procedural stuff.

In fact, if you go that far, I'd suggest turning the entire mod over to you, since you are the one doing all the work (if you are willing, of course).

[TK421d]

i'm late to this party, but just happened on it.

 

as for the earlier "why not both" concerning the bolt plates:

 

i would suggest both in one, keeping it simple by changing the rail ends to conic or pyramidal and just adding bolt holes via texture and normal maps.

like so

Edited July 12, 2017 by TK421d

[Bit Fiddler]

I am leaning toward the new style any way... I am working on the complete lineup in that last style I posted where the mount point is midway down the handrail portion.  it may or may not have the detail like bolts etc.  I have not decided on that yet.  but I like the single mount point and the rounded end caps on the hand holds so I think I am going to stick with that.

[sidfu]

@Linusgurugamer can u remove extra MM thats inside the NEBULA folder. for some weird reason it was causeing issues with my custom kerbalism setup. its weird as i thought MM was suppose to disable other MM dll if a newer version is found first. but it seemed like the 2.8 that was in the NEBULA folder was causeing removal of some nodes and double  adding other nodes almost like both MM where running at start.

 

 

[Eugene Moreau]

Has anyone thought of making some of them procedural or like a strut where you specify the start and end points?  

Apologies if this has already been discussed, I looked though this thread, but not the original.

[linuxgurugamer]

Nope.

You are, of course, free to write it yourself :-)

For me, these are just some parts I wanted.  I'm not really doing much with them

[Sudragon]

@linuxgurugamer thanks for extending the life of this mod. Small request, could you adjust the file structure in the download so modulemanager2.8.0 isn't floating around inside the mod (NEBULA) directory? It just took me several hours to find this and get my copy working properly. (the latest iteration of SSTU was not loading properly, amongst other things).

It's still a very useful add on and I hope it stays on your update list.