User talk:SignpostMarv Martin/llVectorSystem

From Second Life Wiki
Jump to: navigation, search

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