Hoses


Hoses
#1
I'm trying to setup a collection of hose templates for use in the upcoming LDCad Alpha, but I find some of the parts in the library a bit confusing.

For example in the Flex hose 754 and 756 the !Help comments say 'place a string' but the exact spacing isn't mentioned. I've attached my current version. It uses the non deform method for generating the part, I would prefer to use deform but there isn't a suitable donor for this in the current official library.

Secondly: the technic hose (79 and 80), should it start with a static part (pin length or something, like the widening part on pneumatic hoses) or should it bend from the very outer tips?

Attached is my current version for a flex hose, but It's probably the wrong scale. Do note the length isn't restricted so I'm looking for the correct scale on segment level.

I probably will have more questions about other parts later on. Also if someone would like to see additional flexible parts prepared let me know and I'll try model them too.

Any help / insight would be appreciated.


Attached Files
.ldr   flexHose.ldr (Size: 6.44 KB / Downloads: 3)
Reply
Re: Hoses
#2
Roland Melkert Wrote:It uses the non deform method for generating the part, I would prefer to use deform but there isn't a suitable donor for this in the current official library.
I don't quite get what is a suitable donor file for this kind of part. Imho it could be done with a fixed torus, joined to the next element with a deformable cylinder. If so it's easy to do, but I don't really see how to add this in official library since there are already official parts for that.

Quote:Secondly: the technic hose (79 and 80), should it start with a static part (pin length or something, like the widening part on pneumatic hoses) or should it bend from the very outer tips?
I'd say flexible to the very tip. If a straight tip is needed, you just need to add a new path point. This is imho the most flexible solution (pun intended...).
Reply
Re: Hoses
#3
Philippe Hurbain Wrote:I don't quite get what is a suitable donor file for this kind of part.

An optimal donor would be a single segment (or base pattern if you like) without overlap and using as little geometry as possible (no internals, not even duplicate edges resulting from primitive usage etc). This to limit filesize explosion.

Philippe Hurbain Wrote:but I don't really see how to add this in official library since there are already official parts for that.

Donors don't need to be in the official library, I just limit my 'out of the box' collection to the official library so people don't have to install additional stuff. I'll probably add a small collection of LDCad specific donors for use with the deform method (no dependencies for external viewing) in the 2nd 1.2 version.

Philippe Hurbain Wrote:I'd say flexible to the very tip. If a straight tip is needed, you just need to add a new path point. This is imho the most flexible solution (pun intended...).

Funny, didn't even think about it that way. I was thinking about the caps (79.dat) like with connectors in electric wires etc. But you are tight this part can be used 'capless' just as easily using three segment sections. Same goes for technic flex system parts and the flexible axle (although that last one seems to be mainly hardcoded (no subparts))


Thanks for the feedback.
Reply
Re: Hoses
#4
Roland Melkert Wrote:I would prefer to use deform but there isn't a suitable donor for this in the current official library.

What do you mean be 'use deform' here?

Tim
Reply
Re: Hoses
#5
The deform method will take a donor part (e.g. 166.dat for pneumatic hoses) and will apply a different matrix for each vertex so you'll get a seamless pneumatic hose. You could still optional use the references method (like LSynth) does, but it will leave gaps on sharp corners etc.

Attached is a small model using deformed hoses. And one showing the difference between deform and references.


Attached Files
.mpd   pneuTest.mpd (Size: 1.54 MB / Downloads: 4)
.mpd   deformVsRef.mpd (Size: 296.8 KB / Downloads: 3)
Reply
Re: Hoses
#6
Quote:An optimal donor would be a single segment (or base pattern if you like) without overlap and using as little geometry as possible (no internals, not even duplicate edges resulting from primitive usage etc). This to limit filesize explosion.
So I guess that primitive usage in donor files is of little or no benefit, since they can't be freely deformed and need to be inlined by your program...?
Reply
Re: Hoses
#7
The problem is that in hose you cannot use primitives other than triangles since every hose segment is someway different from any other.
Furthermore LDraw based softwares are not able to read complex data structures like triangle stripes or indexed based geometry indicating with that an ordered list of vertices with a list group by 3 index pointers defining faces.

I do not use primitive deformation in SR3DBuilder since it is a bit too much time consuming and do not allow geometry optimization: if you use a primitive, it need to be completely loaded in memory and managed and this causes too many vertex to work with.
Also, be aware from ribbed hose actual definition! It takes over 6500 vertex to define a single segment!

Sergio
Reply
Re: Hoses
#8
Sergio Reano Wrote:The problem is that in hose you cannot use primitives other than triangles since every hose segment is someway different from any other.
Yes, you're right - even quads are not usable since they would get warped!

Maybe it would be possible for some parts to use a mixed mode approach? Fixed, non-deformable "middle" section, joined by a stretchable/deformable part? That wouldn't decrease the poly count, but create much more manageable file size.

Quote:Also, be aware from ribbed hose actual definition! It takes over 6500 vertex to define a single segment!
Agreed, present usage of tori in this part is total overkill!
Reply
Re: Hoses
#9
Philippe Hurbain Wrote:So I guess that primitive usage in donor files is of little or no benefit, since they can't be freely deformed and need to be inlined by your program...?
Yes a donor will be flattened and used as a collection of triangles and lines only. Those same triangle and lines will be 'dumped' into the resulting model as a fallback so all other LDraw software knows how to render the hose or whatever.

If filesize becomes an issue, you could always reconfigure the part to use static references instead of the deform method, it will then just dump type 1 lines much like LSynth does.
Reply
Re: Hoses
#10
Philippe Hurbain Wrote:
Sergio Reano Wrote:The problem is that in hose you cannot use primitives other than triangles since every hose segment is someway different from any other.
Yes, you're right - even quads are not usable since they would get warped!

Maybe it would be possible for some parts to use a mixed mode approach? Fixed, non-deformable "middle" section, joined by a stretchable/deformable part? That wouldn't decrease the poly count, but create much more manageable file size.

Quote:Also, be aware from ribbed hose actual definition! It takes over 6500 vertex to define a single segment!
Agreed, present usage of tori in this part is total overkill!

Actually the amount of vertices aren't really a problem (besides filesize), I've tested setups using over a million triangles in a single flexible part, this part renders at over 1000fps. The only bottleneck is generating the mesh though like Sergio indicates. But because I work with 32bit indices anyway (some official parts have more then 65000 vertices) all the base mesh handling code is already there. And with VGA cards having a couple of gigs of memory these days all should fit nicely in vbo Smile

As for mixed deform and references this is possible in the current version, so if you figure out a configuration which is the best of both worlds for the flexhose I would happily include it in the default collection of templates.
Reply
Re: Hoses
#11
Sergio Reano Wrote:Furthermore LDraw based softwares are not able to read complex data structures like triangle stripes or indexed based geometry indicating with that an ordered list of vertices with a list group by 3 index pointers defining faces.
I would love to see a type 6 and above for this, or at least a way to add per vertex normals for the type 3 and 4 lines (for smoothing).
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 6 Guest(s)