Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[hector13]

…

why?

[King Zultan]

Why did you chart Doctor Who?

Also what's in the spoiler because the image isn't showing for me.

[Funk]

…

why?

Why did you chart Doctor Who?

Why not?
It's a challenge and a way to make sense of what's going on.

Also what's in the spoiler because the image isn't showing for me.

Its a huge chart diagram of the doctor relationships, i mean huge and deep as in the 8th doctors vampire barber.
Try opening it directly as an image,  https://i.imgur.com/oPLK32U.png

[King Zultan]

That's quite a big chart you've got there, looks like you're way more into the show than I am as I've never attempted to do something like that for a show I enjoy.

[Lord Shonus]

Lucid chart is a crap show, my doctor who chart is gone.
Hours of work mapping how every one is related by marriage, murder and 90's one night stands is gone.

Spoiler:  AKA this thing. spoilers. (click to show/hide)

For something like this, and I'm being entirely serious, programs like Trizbort that were made for mapping text adventures would probably work well, as long as you don't mind the lack of graphics.

[TD1]

I'm just lol-ing at the confluence of lines around Jack and River respectively.

[Funk]

For something like this, and I'm being entirely serious, programs like Trizbort that were made for mapping text adventures would probably work well, as long as you don't mind the lack of graphics.

It looking pretty was the appeal of doing it, but i might use that if i remake it.

[Starver]

I have very little experience of (I presume, given context) visual relational-database engines... (Mis)using something like Excel (borders as lines, as well as containers), or fighting with Visio to make it not auto-route inter-box connectors in silly/unaesthetic ways. It's almost worth doing it with actual physical string, the floor equivalent of the Wall Of String trope[1].

But it's definitely hard to intuitively organise. I note the many compromises you already had, and a flat image (and a way to concoct it, from meta-data?) isn't going to do it justice. I saw an "Extended VR(X?)ML" thing, once, that did something with both content and context (and, presumably, style) that might have helped. Even though it only gave three dimensions, where perhaps for Who you'd need more than that[3]. Not sure if it needed a separate plugin (or an embedded .js canvas-using method) to operate, these days. Or where you'd find it, but maybe it's something worth searching for?


[1] Unrelated to this, but because (so long as you can keep it from tangling on first grab, untying and retying when you need to pass one bit 'through' another during the setup) you can even do a 'shortest path' test that's not subject to the computational limitations of Travelling Salesman-type problems. O(1), I suppose!

[2] Until mentioned by others, I hadn't seen River/Jack at all, despite scrolling it all round, then once someone prompted me to go back I spotted them (duplicated, for context obviously). Couldn't see Jackson Lake anywhere (ok, just one 'green line' relationship, which maybe Astrid should earn too), must have missed the Valyard's spot (wherever that should be placed, along with the Hidden Doctor and all the other previously hidden lineage), various Leela links/progressions and I must only presume that the various linkable Oswalds are in some bit of the image I haven't read properly. ...that was just first thoughts, though. Doesn't help your computer problem, either.

[3] Well, faux-dimensions by alternate colour-schemes, shading, shape, etc, can add additional meta-depth to however many dimensions you can exploit more freely.

[Starver]

...speaking of connecting lines (but otherwise unconnected), I'm creating some SVG source with externally calculated coordinates, plugged into a static file... (I'm not looking for adding inline/external javascript, or similar. I'm fine-tuning the drawing coordinates, still, but once I've done that there's no reason to do more work on the pathing.)

For some bits, I have what would basically be (in line-segments) <path d="M X1 Y1 X2 Y2 X3 Y3" /> (all absolute positions, with actual numeric values instead of '[X|Y][1|2|3]'... move to a 'P1' of "X1 Y1" and then implicitly draw the line to P2 and then another onward to P3).

If the three points are calculated as being near-enough colinear[1], then it's good enough to d="M X1 Y1 X3 Y3", but otherwise I'd rather use an arc of the circle that passes through the three Ps. Right now I'm using the sequence d="M X1 Y1 A r r 0 0 0 X3 Y3" ('A' is the Arc command, rx==ry so two 'r's, then zero rotation necessary, short-arc (second 0) and, because of the way it's sorted I can currently guarantee that it's the same handedness of solution (third 0) on the way to the end coordinates). With the expectation that I can d="M X1 Y1 A r r 0 0 0 X2 Y2" (or use as part of a longer path) just to pen the exact same path/boundary but only to the midpoint, or "... X3 Y3 A r r 0 0 1 X2 Y2 ..." on the differently partial 'reverse' path, and yet follow the same P1->P3 curve.

But I'm getting inconsistent responses to the 'r's I'm giving.

I've tried working it out[3], but for self-similar triples (translated/rotated, but otherwise congruous) I'm finding I have to manually tune the value completely differently to what I think my calculus suggests until it renders aesthetically and visually most correct-looking. So it's awkward. Or I've messed something up/misunderstood the syntax.

I perhaps could use "... X1 Y1 Q XC YC X3 Y3 ..." for a single-controlpoint bezier curve, but XC YC would need to be an away-from the circle-centre adjustment of the X2 Y2 (often close-enough the curve midpoint to not worry too much about skew) by some factor or function of the true radius so that the line passes over P2, or within the line-width of it. And  "... X1 Y1 Q XC YC X2 Y2 ..." / "... X3 Y3 Q XC YC X2 Y2 ..." would need entirely new (X|Y)Cs derived from calculated points P1.5 and P2.5. Even if the handedness of the curve would still then be self-evident without having to flip the given flag if reversing the sequence. Additionally, I could just build up a poly-bezier (shortcut with successive "T" path instruction(s)) to get P1->2->3 matching any other Pn->m that should coincide it or part of it.

Or maybe use the double-controlpoint bezier ("C" code, with or without its "S"-continuation). But I can even less work out how to derive all the (X|Y)C(1|2)s that would give a sufficiently circlelike path from that approach.


So... Does anyone have the same fetish as me for (semi-)handcrafting SVG, and perhaps know of a trick I may have missed/messed up along the way? I'm clearly more used to non-curving segments, as you can tell, or yer actual full circles dotted around, filled or in outline. 


[1] I'm arctanning the angles of each segment, and if the values of the two differs less than a convenient value (currently 0.1, of the radian-computation; I may well adjust that threshold[2], but it currently nicely delineates the cluster of states) then it's straight-enough for me!

[2] It's less problematic than (for example) working out the y=mx+c constants and comparing the 'm's, given the non-linearity of relative magnitude vs relative combined orientation and tendency to go to undefinable/infinite for vertical lines. And, though I don't have acute angles (doubling back), I can trap that if necessary.

[3] Effectively doing the divider/straight-edge method. Midpointing P1->2 and P2->3, sending off perpendiculars, calculating the crossing coordinate that'd be the circle centre PC and using the magnitude of |P[1..3]-PC| as what I understand would be the value of rx and ry (which I've checked isn't being taken as an absolute coordinate).

[McTraveller]

Dot (and components of cross)  products are powerful tools, and much faster than arctan.

[Starver]

Dot (and components of cross)  products are powerful tools, and much faster than arctan.

Probably. I did the arctan test as a starter, before I even decided whether I'd go down the route of determinants or gradients, for example, and all I knew is that I'd prefer the 'straight' threshold to be similar whether it was a nearly-vertical line compared to a vertical one or a nearly horizontal line compared to a horizontal one. And that would cause issues in the ((x1-x2)(y3-y4))-((y1-y2)(x3-x4)) or (m1-m2) calculation (if not any m=dx/dy precursor, when I actually have infinite slope). So I just cast this straight to angle (a friendly arctan2(dx,dy) function that means I don't have to worry about catching the sign issues (or potential zero) in the dx/dy myself. It's not a real-time thing, just a handy filter that I don't have to worry about 'uncrossing some part of the cross product' for, accidentally, when push comes to shove.

(Then I did have to worry about four x and four y variables properly used. Or rather the original three pairs for the two joined lines, two pairs for the (trivially calculated) midpoints, and two more for the cast-off perpendiculars (midpoint+<original yDiff,-original xDiff> ...probably the second most trivial bit to it all) before pushing these two latters into the intersection-finder, as I then fully went with the determinant method when I was working out what I wanted to work out. But only for any coordinate onward pair that already passed my trig test of not being sufficiently non-colineyC .)


But what I was really looking for was a "x1 y1 <centredefinedarc> xC yC x2 y2" sort of SVG solution to replace the current "A"-command where it needed radius (which seems to work inconsistently) and explicit flags to choose which of four arcs.

Spoiler: Which was probably too specific an ask to be created especially for me if it didn't already exist (click to show/hide)

But after some thought (after my post) I decided that I was also being to specific. It couldn't ever be asked to do the "big arc" (the direction of arc being implicit in the offset of the 'centre point control coordinates', but it could only then do the small arc - not that I want anything other, but it'd be more useful in general to do), and should it be constrained by |P1-Pc|==|P2-Pc| (i.e. circular radii) or should it be allowed to spiral in/out in a handy polar coordinate r=m.theta way? And by adding just one further value, the offset number of revolutions, the new path command can specify both 'greater arcs' and multiturn spirals! With "x1 y1 <commandLetter> xc yc n x2 y2" I get my arc (assuming I give the right equidistant xc,yc) with n=0, a large-arc sweep can be given with n=-1, a useful curve[1] unlike those given through either Bezier or classic-Arc commands can arise from non-equidustant xc,yc and with 0<n//n<-1 you have spirals (or a space-saving multi-loop path such as is useful to SVG animation).

The only thing I couldn't work out is which command letter to propose. "S"(piral) is taken already for one of the Bezier shortcut notations, and even the technically incorrect "H"(elix) is used for the Horizontal Line. But I'm sure someone is already working on this, if it's actually worth updating the SVG spec for it! So it's doubly useless me going on about it in this forum!

[1] To be even less constraining, archimedian spirals/etc should all be possible, but that either requires anothe flag value to specify or multiple "S"piral command letters to cater for each polar-progression deemed useful.

...so the question I gave currently has no answer, and I shouldn't have asked it. Or the answer I instead had already ended up using was non-optimal in other ways, but at least it clarified things in my mind to set it down. Even if nobody magically discovers that something exactly like what I want was right there all along (before I've moved onto my next unrelated thing to fiddle with and started to newly bore anyone about who'll be forced to hear my newest ramblings).

[McTraveller]

You're just trying to draw the smallest circular arc that touches three points?  Is that right?  I think you can "fix" this simply by just not making the rx and ry the same - if you treat your control points as corners of a rectangle in which you inscribe an elliptical arc you will get a more consistent behavior - but it won't pass that arc "through" P2. To get curves through each point - I'm pretty sure in SVG this means you will need two SVG paths - one between each pair of points.  So you do in fact need P2 as an endpoint - like an arc between P1 and P2, then another between P2 and P3.

If I'm understanding it correctly, that is...

Spoiler: regarding dots vs arctan (click to show/hide)

So I was suggesting to use a dot product as a proxy for converting slope to angle to decide if things are collinear.  If you have three points A,B,C, then there are two vectors P = B-A and Q = C-A.  Since P dot Q = |P||Q|cos(the angle between them), then you can just do "if P dot Q minus |P||Q| is small enough" then they are collinear - no divisions needed. You can probably do "P dot Q / |P||Q| is roughly 1" safely as well, and that will "normalize" to account for a large dynamic range of distances between points.

[Starver]

...erm, long reply, rambled a lot. To save the rest of you the boredom (and it's past my own theoretical bedtime!) I've cut it and I'll paste it into a PM instead.

(In all humility, though might have been kindest to save even McT my combined drivel.)

[Schmaven]

I'm curious if you had plans to also implement a character string variable at points A & C, and animate the resultant curve plots to a network of connected variables that might be able to be arbitrarily repositioned and connected with mouse input.

[Starver]

I'm curious if you had plans to also implement a character string variable at points A & C, and animate the resultant curve plots to a network of connected variables that might be able to be arbitrarily repositioned and connected with mouse input.

In short, no. I've been a good little programmer and added distinct "id="s to virtually every element, of course, but mostly as a handy descriptive (if somewhat cryptic/abbrvted!) internal label. No intention of recalculating anything dynamically once projected onto the final 'canvas'. What I get, at the end, is just the final static product that satisfies a thought experiment and surely needs no additional changes to wow the world.

Spoiler: That's if it gets that far. (click to show/hide)

It's a delve into something that seemed like something I might try, a few weeks back, and may (and, I predict, will) never itself fully see the light of day outside the bounds of my own house.

And, besides, I'd need to convert both convoluted Excel formulae and self-obfuscating Perl script (into which I have passed stuff, got it to reassemble other stuff in return and I then pasted it into an aesthetically pleasing bit of a text file with perhaps some whitespace needing lining up to look good[1]) into passable .js that I need to be sure has caught the mad limits of whatever restructuring I let it do (rather than the current visual check, ponder, then change a rogue + to a - or whatever was wrong but didn't matter until the special case it was meant to handle hadn't cropped up).

The basic plan here was "yeah, that actually works" then start on the next mental distraction, forgetting half the lessons I just learnt. The latter bit not actually the plan, but typically my expectation in such scenarios.


[1] In case someone wants to view the flat markup and see slightly more than character-soup. But that someone will only be me, anyway. It'll still help, but not enough to just automate the respacing bit (or even the entire SVG composition) in the first place! But occasionally lining tbings up nicely by hand is my particular art speciality. And the limit to my talents, too.

Which is not to say that I might not show (not tell) something actually worthwhile to you all, eventually. Probably not this, though, which I appreciate is frustrating unless you like the theoretical elements more.