User talk:SignpostMarv Martin/llVectorSystem

List of Attendees

Transcript

[4:26 SLT] SignpostMarv Martin: so I had this idea last night
[4:26 SLT] SignpostMarv Martin: llVectorSystem()- like llParticleSystem(), but for drawing arbitrary vectors
[4:26 SLT] SignpostMarv Martin: ome usages of llParticleSystem() are used to just draw lines between two points, using a variety of different textures to try and "fake" a solid line
[4:26 SLT] SignpostMarv Martin: some*
[4:27 SLT] SignpostMarv Martin: I'd imagine that the code would be basically similar to the llParticleSystem() code that calculates the path that particles should take,
[4:27 SLT] SignpostMarv Martin: except the path is rendered
[4:27 SLT] SignpostMarv Martin: could be used for diagrams, wires, art, direction hints etc.
[4:27 SLT] SignpostMarv Martin: even laser beams :-P
[4:28 SLT] SignpostMarv Martin: thoughts ?
[4:29 SLT] 010000100111001001100001011011 Omlet: I like chocolate milk.....
[4:30 SLT] SignpostMarv Martin: regarding the function :-P
[4:30 SLT] SignpostMarv Martin: do you think there's much need for it ?
[4:30 SLT] Saskia McLaglen: put it in the jira new features and see
[4:31 SLT] SignpostMarv Martin would rather get peer discussion on the idea before adding it to the jira
[4:31 SLT] Serendipity Fegte: binary guy is 278698075 in decimal - pfffft thought he'd be more interesting.. :(
[4:32 SLT] 010000100111001001100001011011 Omlet: (throw a 10 on the end of me and then try agian)
[4:33 SLT] Serendipity Fegte: 1114792302 ?
[4:33 SLT] Randur Source: 4272616E hex?
[4:34 SLT] SignpostMarv Martin: there's the matter of whether there should be a seperate function for this,
[4:34 SLT] SignpostMarv Martin: or if it should be expanded into llParticleSystem()
[4:34 SLT] SignpostMarv Martin: e.g. PSYS_RENDER_PATH
[4:34 SLT] Serendipity Fegte: tries to transalte to l33t
[4:34 SLT] Serendipity Fegte: or fromt l33t to english rather...
[4:34 SLT] Serendipity Fegte still doesn't get it
[4:36 SLT] SignpostMarv Martin: does it make sense to use a seperate function over extending llParticleSystem() ?
[4:37 SLT] SignpostMarv Martin: are people going to want to do things with drawing vector paths that they couldn't do with particle parameters?
[4:40 SLT] Elbereth Witte: particle parameters are obnoxous, and I don't think theres a huge overlap with its settings and settings taht might be used for vectors
[4:42 SLT] SignpostMarv Martin: see previous blurb: [4:27] SignpostMarv Martin: I'd imagine that the code would be basically similar to the llParticleSystem() code that calculates the path that particles should take,
[4:27 SLT] SignpostMarv Martin: except the path is rendered
[4:43 SLT] SignpostMarv Martin: I don't use llParticleSystem() often enough to know whether there'd be more than just the "draw line of partcles between object A and object B" stuff
[4:43 SLT] Elbereth Witte: I'm not sure I see more than kooshballs being made with that
[4:43 SLT] SignpostMarv Martin: kooshballs ?
[4:44 SLT] Elbereth Witte: eh, an old rubber ball made of strands that come from the center, lemmie hit google
[4:44 SLT] SignpostMarv Martin: ah
[4:44 SLT] SignpostMarv Martin: i know what you mean now
[4:45 SLT] SignpostMarv Martin: vector paths could be used to replace particle streams wherever the user wishes to draw a line
[4:45 SLT] SignpostMarv Martin: wires, chains etc.
[4:45 SLT] SignpostMarv Martin: the idea came to me while playing WoW
[4:45 SLT] SignpostMarv Martin: fishing line
[4:45 SLT] Elbereth Witte: I see the use of drawing lines in space, I just don't see LL making a whole new rendering feature for it
[4:45 SLT] SignpostMarv Martin: I don't believe we have anything in Second Life that can create a dynamic wire in 3D space that looks contiguous
[4:46 SLT] Elbereth Witte: and the old particlesystem is kinda scary
[4:46 SLT] SignpostMarv Martin: it could be used for diagrams
[4:47 SLT] Elbereth Witte: I'm well sold on the uses, I just don't see it hapening, ani I would cry if I saw it happen, but tied to particlesystem
[4:47 SLT] SignpostMarv Martin: okay, lets think of some crazier users that wouldn't be possible to do with the llParticleSystem() parameters
[4:47 SLT] SignpostMarv Martin: doodling spirals
[4:47 SLT] Elbereth Witte: actually, spiral could be done
[4:47 SLT] SignpostMarv Martin: can a particle stream be sent in a spiral ?
[4:49 SLT] Elbereth Witte: though, each particle goes straghtish, so it probably woludn't work like we think
[4:49 SLT] SignpostMarv Martin: think about the path the particles take, rather than the visual effect
[4:49 SLT] SignpostMarv Martin: what params would you use to doodle a spiral of particles ?
[4:49 SLT] Elbereth Witte: one with the particle actually spiraling? I would fail after half a loop
[4:50 SLT] SignpostMarv Martin: any particle wizards in the room ? :-P
[4:50 SLT] Saskia McLaglen: angle, omega, target self, and possible targetOmega on the emitter too
[4:50 SLT] SignpostMarv Martin: hrm
[4:50 SLT] Elbereth Witte: omega sedns the particles straight out though, the visual effect is a spiral, the particles don't do that though
[4:51 SLT] SignpostMarv Martin: but it could be "faked" if you drop a dot and trail it through 3D space ?
[4:51 SLT] Saskia McLaglen: if the radius is wide, and they target the emitter, they can be made to spiral in
[4:51 SLT] Elbereth Witte: I see this useful for fishing line, I"m not overwhelmed by that, generating a single vector from point to point
[4:51 SLT] Elbereth Witte: they won't orbit though, which I suspect is what the interpretation would need
[4:52 SLT] Saskia McLaglen: hmmm...maybe scratch that, i am using two emitters targetting a central prim..sorry
[4:52 SLT] SignpostMarv Martin: what about beizer curves ?
[4:52 SLT] Elbereth Witte: limited I think, and again just one per emitter
[4:52 SLT] Talia Tokugawa: PSYS_PART_FOLLOW_SRC_MASK and llSetTargetOmega?
[4:53 SLT] Elbereth Witte: they'd go out and come back, straight lidne to/from
[4:53 SLT] Talia Tokugawa: straight paths in relation to the emitter but spirals in global space....
[4:54 SLT] Elbereth Witte: spirals in appearance by the relative particle pattern
[4:54 SLT] Elbereth Witte: the paths are straight though
[4:54 SLT] SignpostMarv Martin: like say you wanted to draw a route for an avatar to take through a sim without using multiple prims
[4:56 SLT] Elbereth Witte: go to another game platform I'd suggest
[4:56 SLT] SignpostMarv Martin: :-P
[4:57 SLT] SignpostMarv Martin: the other alternative use would be to create dynamic fake (or taking real innput) oscillioscopes
[4:57 SLT] SignpostMarv Martin: object to object path, with beizer curves to go around objects
[4:57 SLT] SignpostMarv Martin: like you could tie in some voice-activated gestures into a mouth piece on a robotic avatar,
[4:57 SLT] SignpostMarv Martin: and create some freaky fake voice synth patterns
[4:58 SLT] SignpostMarv Martin: with higher quality than you could with a texture animation
[4:58 SLT] Elbereth Witte: I'd greatly appreciate vectors, but llParticleSystem is a corpse that won't stay buried, and won't put on any deodorant
[4:58 SLT] SignpostMarv Martin: lol
[4:58 SLT] SignpostMarv Martin: okay, lets think about it from a technical angle
[4:59 SLT] SignpostMarv Martin: how would you specify a beizer curve in a list ?
[5:00 SLT] Elbereth Witte: well, if its going to be a list thing, you'll probably have a line type, start and end points, plus any extra data for the type in each declaration stride
[5:00 SLT] Elbereth Witte: VECTOR_BEZIER, startvec, endvec, startang, startpow, endang, endpow?
[5:02 SLT] Elbereth Witte: though, that ignores animation entirely, which would be choppy the way I"m thinking of it and the way they'd do it...
[5:02 SLT] SignpostMarv Martin: hrm ?
[5:03 SLT] Elbereth Witte: question ! I think is how limited will the function be
[5:04 SLT] SignpostMarv Martin: what about VECTOR_BEZIER,vec,ang,pow,vec,ang,pow,vec,ang,pow,vec,ang,pow....
[5:05 SLT] Elbereth Witte: if it only ever does one line segment, sure
[5:07 SLT] Elbereth Witte: problem with an unbounded attribute like that though, is making it coexist with all the prettifying attributes, color, glow, etc
[5:07 SLT] SignpostMarv Martin: the purpose would be to be able to draw a very wavy line by using only one prim
[5:07 SLT] Elbereth Witte: I figure to make a runon bezier, just specify many bezier segments
[5:07 SLT] Elbereth Witte: VECTOR_BEZIER, startvec, endvec, startang, startpow, endang, endpow, VECTOR_BEZIER, startvec, endvec, startang, startpow, endang, endpow, VECTOR_BEZIER, startvec, endvec, startang, startpow, endang, endpow
[5:07 SLT] Elbereth Witte: though, thats not horribly efficient I know
[5:08 SLT] SignpostMarv Martin: how would it know where to place the curves ?
[5:08 SLT] dibbs Dovgal: It would be nice to enable the link of two BEZIERs so you do not have to duplicate start and end points at the connections
[5:08 SLT] Elbereth Witte: it'd be relative to the drawving prim
[5:08 SLT] Elbereth Witte: it'd be nice, but how without a runon declaration?
[5:08 SLT] SignpostMarv Martin: equal relative distance between the end point and the emitter ?
[5:09 SLT] Elbereth Witte: well, I figure the start and end wectors would be absolute relative coords
[5:09 SLT] SignpostMarv Martin: so a single bezier would put the curve in the middle ?
[5:09 SLT] SignpostMarv Martin: ah
[5:11 SLT] SignpostMarv Martin: what about animated vector paths ?
[5:11 SLT] SignpostMarv Martin: should they be supported in the list of params, or just done like the particle system ?
[5:11 SLT] SignpostMarv Martin: e.g. fire off multiple calls
[5:12 SLT] Elbereth Witte: fire off multiple calls is the obvious one that will happen either way
[5:13 SLT] Elbereth Witte: for actually supported anims you probably would want to figue out how to associate the line segments more closely than what I've stuck with so far
[5:14 SLT] SignpostMarv Martin: include a "transition from previous settings" param ?
[5:14 SLT] Elbereth Witte: or teh anim could be based on warping the space those points are set in
[5:14 SLT] Elbereth Witte: then each segment would probably have to be named or numberes somehow
[5:15 SLT] SignpostMarv Martin: the alternative I'd imagine would be a VECTOR_NEW_SET type parameter
[5:15 SLT] Elbereth Witte: still need to give each segment an identity to associate old with new I think
[5:16 SLT] SignpostMarv Martin: so you just drop that into the middle of a list, and it starts anew, as opposed to drawing a vector back in on iself
[5:16 SLT] Elbereth Witte: oh, for the runon type of declaration?
[5:16 SLT] SignpostMarv Martin: yar
[5:17 SLT] Elbereth Witte: I"m not sure I've seen any list parameters in LSL have a flexible number of arguments yet...
[5:17 SLT] SignpostMarv Martin: llSetTexture
[5:17 SLT] SignpostMarv Martin: or rather the thing with llSetPrimitiveParams for setting texture
[5:19 SLT] Elbereth Witte: PIRM_TEXTURE looks like it has a fixed number of arguments
[5:19 SLT] SignpostMarv Martin: VECTOR_START,float transition,startvec,endvec, startang, startpow, endang, endpow, VECTOR_START,VECTOR_START,float transition,startvec,endvec, startang, startpow, endang, endpow, ....
[5:19 SLT] SignpostMarv Martin: you can put in multiple PRIM_TEXTURE groups into llSetPrimitiveParams(), enabling you to set multiple textures on different sides in a single call
[5:20 SLT] Elbereth Witte: net much different than using multiple vector draw segments to form a single path
[5:20 SLT] SignpostMarv Martin: sort of
[5:20 SLT] Elbereth Witte: but doing taht with one PRIM_TEXTURE would be the exception I'm looking to see demonstrated
[5:21 SLT] SignpostMarv Martin: if ya think about it, PRIM_TEXTURE supports up to 8 groups,
[5:21 SLT] SignpostMarv Martin: though if you have different meshes with more max. available sides.....
[5:22 SLT] Elbereth Witte: my point is that its always a fresh command with fixed args
[5:24 SLT] SignpostMarv Martin: hrm
[5:25 SLT] Elbereth Witte: they could'nt even be bothered to make a straight vector definition interface to sculpties, forced textured shapes on us :-)
[5:25 SLT] SignpostMarv Martin: what would be fun is if you could put PRIM_TEXTURE,{params},PRIM_DELAY,0.5,PRIM_TEXTURE,{params}
[5:25 SLT] Elbereth Witte: delay list execution, cute
[5:26 SLT] Elbereth Witte: I bet they don't want to risk any functions becoming turing cemplete though :-)
[5:27 SLT] SignpostMarv Martin: :-P
[5:27 SLT] SignpostMarv Martin: so we should probably have two seperate feature requests here then :-P
[5:28 SLT] Elbereth Witte: llCrushKitten and llMangleKitten?
[5:28 SLT] SignpostMarv Martin: "llVectorSystem()" & "list-based parameters with delayed execution to reduce network usage"
[5:32 SLT] Elbereth Witte: I"m still hoping for my llPlayFunkySoundList(); idea to appear in some form, listing a sound, playspeed, delay till next sound, etc
[5:32 SLT] SignpostMarv Martin: how laggy does a club get if it uses llSetPrimitiveParams() to make lights flash etc.
[5:33 SLT] Elbereth Witte: primparams is pretty lazy
[5:34 SLT] Elbereth Witte: the ability to change playback pitch, would be HUGE
[5:40 SLT] Elbereth Witte: client already has it for doppler shifting
[5:40 SLT] SignpostMarv Martin: mind if I post this chatlog on the wiki ?
[5:41 SLT] Elbereth Witte: me complaining that the current paradigms are too painful to do anything decent with? have fun

Generated by SL Chatlog Wikify

User talk:SignpostMarv Martin/llVectorSystem

List of Attendees

Transcript

Navigation menu

Search