Jump to content

[WIP] THSS - Tri Hexagonal Structural Truss Reborn (v1.0 RC1 -7/19/14 )


noonespecial

Recommended Posts

I'm having a few issues that are slowing my progress.

The first issue is a scaling issue. I'm still learning Blender, so I'm doing must of my models in Sketchup and using Blender for post processing. The problem lies in importing the dae file into blender. Take a look:

Javascript is disabled. View full album

You can see that the sizes of the truss and the radial fuel module fit perfectly (pictures 1, 2, 3). However, when I import them separately into blender, the import as drastically different sizes (picture 4 and 5). I've combed the forums and found several issues with earlier version of SU, but no mention of a scaling problem.

The second issue is with attachment nodes. I've had no problems with Top, Bottom, Left, Right, Front or Back (I just use Blender to find the coords), but I can't seem to figure out FrontRight, FrontLeft, BackRight, or BackLeft. The problem is with the angle. I can get it working with the angx, angy, angz, but it is a time consuming process. Change it by 0.01, reload from debug, VAB, check, rinse and repeat. Is there a better way to configure attachment nodes other than simply plugging in a number, checking the VAB, an adjusting?

Here is a photo of what I mean

PRpBdkw.png

Link to comment
Share on other sites

Use trigonometry!

(the truss can be simplified as a triangle)

The angle should be a multiple of 30 degrees (since the sum of the angles in a triangle =180 ==> one corner is 60 and then half of that is 30)

if it is 30, 60, 110 or 140 degrees offset depends on how KSP has the coordinate system.

The exact coordinate can be calculated using pythagoras theorem and some simple algebra :)

Finally you will have some "real world" use for the algebra and trigonometry from school.

Link to comment
Share on other sites

I hear what you're saying Greys, however, as far as I'm away "THSS" (Tri Hexigonal Structural Struts) is a physical description of the product. JARFR was the mod name. Semni made Jafra THSS, Jafra HOSS, and Jafra CRSS. So I don't believe there would a license conflict. Regardless, if that is the case, I haven't actually named my mod yet. I'd probably go with something silly like NOSTech.

Also, the derivatives refer to the different THSS (THST (Truss instead of Strut)) being created by You, Biotronic, and I. Semantics either way and easily changeable.

As far as sizing them to be compatible with FUSTEK, my opinion is to make the sizing as "stock" as possible and not overly favor one mod or another. If I favor FUSTEK, it wouldn't work well with KSO or KOSMOS. I think the best I could do while keeping with this paradigm is making a FUSTEK "adapter" (an odd sized part to match the stock-sized to FUSTEK). However, I haven't really measured FUSTEK... for all I know my plans are already compliant, haha.

Modeling Update:

As per suggested, I've simplified the parts somewhat, with hopes of duplicating the complexity with texture. In the pictures above, you'll notice a difference between the 1m truss and the 2m truss (2m still isn't finished). I'm also developing an additional variant to show to see which model is preferred before I throw together all the other models.

P.S. Thanks for catching my embarrassing typo... Struss. Not sure if I was thinking Truss and typing Strut and combined them or if I hit a wrong key. Haha

I agree, all Xerox machines are copiers, not all copiers are Xerox, All Bobcat's are skidsteers, not all skidsteeers are Bobcats, all thumbs are fingers, but not all fingers are thumbs.

Link to comment
Share on other sites

This is an example of where NODE{} shines, and why I spent two weeks trying to fix it instead of working on TLHT. PART{NODE{}}, or PART.NODE, is an alternative to PART.node_* for declaring and describing nodes.

Here's an example of the syntax: https://github.com/Greys0/HexCans/blob/RocketParts/Unfinished%20Parts/TLHT/TLHT.cfg#L24-L30

You'll notice the field PART.NODE.transform, that's what lets the magic happen. PART.NODE takes a transform, which is "A GameObject of a specified name which has a specific location and orientation", you can use any gameobject, and that gameobject does not have to do anything else. In which case that gameobject is 'an empty', and being used as a transform.

Here is the transform for Rear3, you can see it, where it is, it's coordinates and rotation; but critically it's heirarchy.

D7izl5I.png

Up until you make use of the heirarchy PART.NODE is just an alternate way of doing the same thing; but.

Look at Rear3's rotation, notice that it's 0, 180, 180; then you can see that in the top right corner of the viewport is the global compass and Y is straight up, so why is Rear3 not pointing straight down? Because of Rear3's parent, side. Side has a rotation of 0, 0, 240 and Rear3 inherits that rotation as if they were physically attached. Similarly Rear2's parent has a rotation of 120, and Rear1's parent has a rotation of 0; so all three sets of these nodes have themselves identical coordinates; they are duplicates of each other, and then their parents introduce a change.

And it works!

YmVPB34.png

Almost. There is a glitch in how parts get loaded that results in PART.NODE.size being ignored; like I said I spent two weeks trying to fix this and got so close but another bug with the GameDatabase that strips PART confignodes of values which are not floats, serialized floats, or enums made it unreasonable for me to do so. However this should be fixed in 0.24, both of it really, and that seems to be in the nearer-than-far future.

PART.NODE basically lets you break down the problem into bits so that you can reuse simple coordinates, but it currently dispermits the use of node sizes other than 1 and that means large structures will be weak. Yours might be fine, size 1 is correct for 1.25m parts anyways.

Link to comment
Share on other sites

Ive got some pictures:

Medium

IsDoc0J.jpg

Large

f45G4rn.jpg

There is a small one too but there's not much point in posting it since it looks like half the medium one.

Each Truss size here corresponds to the large fuel tanks. The large truss is exactly the same size as the Jumbo 64 orange tank. (I used the Jumbo 64's cfg as a guide so the nodes are exactly the same)

I'll be working on the connectors next.

Edited by SpeedyB
Link to comment
Share on other sites

Looking very nice!! I used the original mod this was inspired by and am really glad to see the idea resurrected, They go extremely well with Fustek's station parts =D

Just out of curiosity was there any plans on bringing back the Octostruts, made by the same person? I can post screenshots if you unsure of what im talking about..

Link to comment
Share on other sites

This is an example of where NODE{} shines, and why I spent two weeks trying to fix it instead of working on TLHT. PART{NODE{}}, or PART.NODE, is an alternative to PART.node_* for declaring and describing nodes.

Here's an example of the syntax: https://github.com/Greys0/HexCans/blob/RocketParts/Unfinished%20Parts/TLHT/TLHT.cfg#L24-L30

You'll notice the field PART.NODE.transform, that's what lets the magic happen. PART.NODE takes a transform, which is "A GameObject of a specified name which has a specific location and orientation", you can use any gameobject, and that gameobject does not have to do anything else. In which case that gameobject is 'an empty', and being used as a transform.

Here is the transform for Rear3, you can see it, where it is, it's coordinates and rotation; but critically it's heirarchy.

http://i.imgur.com/D7izl5I.png

Up until you make use of the heirarchy PART.NODE is just an alternate way of doing the same thing; but.

Look at Rear3's rotation, notice that it's 0, 180, 180; then you can see that in the top right corner of the viewport is the global compass and Y is straight up, so why is Rear3 not pointing straight down? Because of Rear3's parent, side. Side has a rotation of 0, 0, 240 and Rear3 inherits that rotation as if they were physically attached. Similarly Rear2's parent has a rotation of 120, and Rear1's parent has a rotation of 0; so all three sets of these nodes have themselves identical coordinates; they are duplicates of each other, and then their parents introduce a change.

And it works!

Almost. There is a glitch in how parts get loaded that results in PART.NODE.size being ignored; like I said I spent two weeks trying to fix this and got so close but another bug with the GameDatabase that strips PART confignodes of values which are not floats, serialized floats, or enums made it unreasonable for me to do so. However this should be fixed in 0.24, both of it really, and that seems to be in the nearer-than-far future.

PART.NODE basically lets you break down the problem into bits so that you can reuse simple coordinates, but it currently dispermits the use of node sizes other than 1 and that means large structures will be weak. Yours might be fine, size 1 is correct for 1.25m parts anyways.

Greys, you blow my mind every time you post something. So, let me make sure I understand what you're doing here. You're creating a GameObject child under the Part>Model named AttachNodes, then creating additional GameObjects under that for each attachment node, then calling those attachment nodes in the part.cfg using "NODE {...}". Do I understand that correctly?

Ive got some pictures:

Medium

Large

There is a small one too but there's not much point in posting it since it looks like half the medium one.

Each Truss size here corresponds to the large fuel tanks. The large truss is exactly the same size as the Jumbo 64 orange tank. (I used the Jumbo 64's cfg as a guide so the nodes are exactly the same)

I'll be working on the connectors next.

Those look very nice Speedy! At first glance, I thought it WAS the original THSS. But I do see some differences in your models. Specifically, you use a hexagon center post as opposed to Semni's industrial truss center post. Very nice work.

Looking very nice!! I used the original mod this was inspired by and am really glad to see the idea resurrected, They go extremely well with Fustek's station parts =D

Just out of curiosity was there any plans on bringing back the Octostruts, made by the same person? I can post screenshots if you unsure of what im talking about..

Hi RNW, as a matter of fact. I am planning on doing an octostruts variant as part of this mod. I have a few ideas sketched up on paper, and will start to model them once I finish the core THST parts. SpeedyB might do a version more true to the original, you'll have to wait for him to answer.

Link to comment
Share on other sites

Just out of curiosity was there any plans on bringing back the Octostruts

I'll be making all the parts from the original mod. The ones there are screenshots of on his original post. (I don't actually have the mod so if there are more let me know)

I'll also make any other parts the I can think of like fuel tank parts. I was also thinking of some other parts like reactors(for inter stellar and/or near future tech), radiators, batteries, solar panels, cargo bays, TAC Life support parts, greenhouse, extra planetary launchpads (it needs new models badly).

Edited by SpeedyB
Link to comment
Share on other sites

I-- euhm, Maybe? I'm still using PartTools 0.18 which is just the script to generate mu files, so I make everything from scratch. I make a bunch of gameobjects, name them how I need, and give them the relevant components.

So here's what you want to end up with, one gameobject which contains a second gameobject. the first one is at coordinate 0, 0, 0 with rotation 0, 0, 0. The second has the necessary coordinates to be at the center of one of your triangles, I suggest with one that is parallel or perpindicular to an axis. Now duplicate the first gameobject twice, the clones should contain clones of the second gameobject. Now modify one of the clones to rotate along the vertical axis by 120 and then 240 degrees. Is that what you said?

Link to comment
Share on other sites

I'll be making all the parts from the original mod. The ones there are screenshots of on his original post. (I don't actually have the mod so if there are more let me know)

I'll also make any other parts the I can think of like fuel tank parts. I was also thinking of some other parts like reactors(for inter stellar and/or near future tech), radiators, batteries, solar panels, cargo bays, TAC Life support parts, greenhouse, extra planetary launchpads (it needs new models badly).

Ive got copies of the original mods in an old game data folder(well the 3 that i know off, THSS, HOSS, and CRSS (which was just 4 parts) , id be happy to throw them up on my dropbox, if you want them for refrence. Unless it break some sort of rules or something. :) Just gimma a holler.

And i totally agree on the new models for Extra planetary launchpads, :P I wish i had some modeling talent, i really would love to see a new furnace for Ex. Planetary.

Link to comment
Share on other sites

Someone else just send my a copy so I'm good there. Ex. Planetary is a mod I've wanted to use for a while but all mods I use must look good. Now that I've got this part making thing figured out I'll make it look good. Not sure how I'll do that recycling bin thing though, maybe a huge grinder. I'll definitely be making a lot of resource storage parts for the Hex Trusses.

Link to comment
Share on other sites

Looking very nice!! I used the original mod this was inspired by and am really glad to see the idea resurrected, They go extremely well with Fustek's station parts =D

Just out of curiosity was there any plans on bringing back the Octostruts, made by the same person? I can post screenshots if you unsure of what im talking about..

As requested.

Here is my version of the Octo Truss. It, with a few other octo parts, will be available in the next release.

3w2p6or.png

Link to comment
Share on other sites

Yeah man, pretty awesome work!

I finished the large Octo tank, I'm working on the Octo to 1.25m adapter and tomorrow I'll finish the Octo to 2.5m adapter.

I have some variants for the Octo Tanks I'll make available as optional downloads. First, the normal one. Second, a transparent tank model. And third, a reflective tank model (using Starwaster's Reflective plugin).

Javascript is disabled. View full album
Link to comment
Share on other sites

Call me biased, but I'm liking that reflective tank.

Can I suggest some normal mapping for it? Not something too extreme, but reflective textures really benefit from it visually.

Good idea. Unfortunately, I'm still trying to figure out normal maps. Can you recommend any good tutorials?

Link to comment
Share on other sites

Good idea. Unfortunately, I'm still trying to figure out normal maps. Can you recommend any good tutorials?

I dont cant think of any, I dont usually use them. I dont have patience for tutorials.

I've made them and I use a plugin from Nvidia for Photoshop. it takes an image and makes the normal map out of that. dark colors are low areas and bright colors are high areas

Link to comment
Share on other sites

I dont cant think of any, I dont usually use them. I dont have patience for tutorials.

I've made them and I use a plugin from Nvidia for Photoshop. it takes an image and makes the normal map out of that. dark colors are low areas and bright colors are high areas

Use normal maps online, which are pretty easy to use. http://www.smart-page.net/smartnormal/

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...