Recommended Posts

:) Can do.  I guess... what I do... is clone the BJS docs repo... into my personal docs repo... using the "fork" button. 

Later, you use the "compare" button, and then the "switch bases" and then "merge"... to "freshen" your personal docs repo... before you do further edits on any docs.  The BJS docs repo will get ahead in commits... while your docs repo sits idle for months.  This action will update YOUR repo... to be even-with the BJS docs repo.  In fact, your repo should report being one commit AHEAD-OF the BJS docs repo... after the "freshen".

I have been known to delete my old docs repo (gotta dig deep to find out how to do that)... then do a fresh "fork" at the BJS docs repo.... to give me a brand new fresh personal docs repo.  THEN I do editing, and pull request of my edits.  But the compare/switch-base/merge refreshing-method works good, too.

Then, wander into the CONTENT/EXTENSIONS folder (on your repo) and create your folder/document in there (using github markdown).

THEN, there is a file called statics.json in the DATA directory.  You must add an entry in there... for your new doc.  Follow established formatting conventions, and be careful not to mess with other things.  Precision is important, here.

Then do a pull request... and the edited statics.json and yourdoc... will be committed by some custodian.

Then, wait for the build.

The Table of Contents for your new doc... is generated during the build.  With github markdown (what you will write your doc in)... a #header is big black text, a ##header is semi-big/black, and a ###header is sort-of big/black.  The dynamic TOC ignores ####headersLikeThis... with four num-signs.

Rumor has it that there are slight differences between 'markdown' and 'github markdown', so when you go searching for markdown cheat sheets, make sure its 'github markdown'.

I think there might be online editors, as needed... with some helper buttons.

You CAN build the entire docs and docs website... on your home computer.  IF you decided to operate that way, you will be able to do your own docs builds and tour our entire docs website... on a localhost web server (thus see the TOC before official commit of your new doc).  But if you just follow the #, ##, ### rules for headers and indented headers, all should be fine.

If it takes a few docs builds to get your TOC right, what the heck?  I know the docs builders love doing builds.  ;)  (it's all automated - with static tutorials/docs marshalled by statics.json)  Know what grunt and gulp, are?  A docs build is a grunting and gulping festival.  I used-to do in-home builds, and you would not believe the amount of logging that comes across the screen... during a ~45-second build.  Its as if 10,000 programs went to work all at the same time, and they are ALL reporting every action they take.  Drool-worthy "batch" processing, for sure.

Maybe that will help get you rolling faster/easier.  I hope so. 

For the demo PG, maybe we should keep it more-simple than the worm crap I am trying.  sps.getMesh() can return us the mesh used for a word.  Then we can use my little animation funcs in lines 2-50 here... or similar createAndStartAnimation calls... on those word-mesh or sentence-mesh.  Simple fly-the-words-into-view stuff... would be impressive, but I guess we would want to show-off the X/Y rotation powers... because BJS GUI textBlocks don't allow that type of rotation (only z-rot).  If folks are simply flying flat-words around, might as well use GUI textBlocks.  It's not until we see your fonts' thickness... that your textMesh really shine and show their differences from GUI textBlocks.

Your textMesh (sorry, I sort of adopted that as the name, but feel free to call it anything, of course)... don't have a color-each-letter feature, unless we make a different Text object for each letter.  SO... maybe we could do some spotlight work in the demo... to make letters flash in sequence or something.  (move spotlight to front of letter, turn on in green for 1/10 sec, then move to next letter, turn on in red for 1/10 sec, etc... for some material effects).

Not sure, yet.  The specular light flash coming from tipping each letter... is pretty cool, too... but it's not jaw-dropping cool.  :)

Have you thought about the "write it vertical" option at all (and its vertical kerning issue.... space between letters)?  Do we have adjustable kerning at all?  Should we?  I need to study the properties on your newest version(s), yet.  I'm a bit behind... on the newest features.

How about "face direction" vector3?  Letters face the sky, or face -z, etc, etc?  Possible?  That complicates the kerning, as you must take the facingDirection into consids when calculating which axis is the kerning axis.  And, of course, if you allow writeVertical, that will need consids, too... as far as determining what direction the kern-spacing must be applied-to.  In other words, it will be possible that each kern-gap.... COULD be some amount of distance on two different axes.  If the word is written with an odd facingDirection vec3, then the kern space between letters (letter-spacing)... could be an odd angle as well.

This stuff is very new, so I don't know WHAT to consider or try to honor... for this baby.  For most of us, this is the first time we've ever been here.  :)  There's really no "best practices" established.  We are still discovering the best practices... on this one.  :)

Worms?  Now what little 6 year old girl wants to learn to read... with "worms" crawling all over the place?  But choo-choo trains... or dancing letters and words with music playing... that's all very inviting.  What's next... you want each word to come marching into the scene... dressed as a warrior, and each word decapitates little Suzie's avatar and guts and blood goes splashing all over?  Huh?  heh.  Maybe word bombs dropped from enemy bombers?  Sentences carried by inbound mortar rounds?   Do first graders in your town... wear Kevlar and combat gear?  :)  (Just havin' fun with ya, of course.)

Share this post

Link to post
Share on other sites

Thank you for the helpful comments.

I went with MeshWriter; this was partially influenced by your constant use of "mesh" in the name -- which is appropriate.  'text' means too many other things in the context, most of them not similar to this.  'glyph' is more on-point but is intimidating and hard-to-spell.

BTW, TextMesh sounds like TexMex when you are quite drunk.

Share this post

Link to post
Share on other sites

Should we call it letter-spacing?  Kern is a sucky word... sounds too much like "gout".  :)

Really, though, you need 3 axis kerning... and allowing negative kern values.

Let's say... for my vertical letters-on-a-rope... that I had a kerning of vec3(0, -40, 0)

That would cause each letter... to be 40 units below the previous letter (-40 Y), but directly under (0 X & 0 Z) the previous letter.

( I'm thinking about this with word facing z-looking cam. FacingDirection 0, 0, -1 )

The Z-value for the 3d kern setting... would HAVE TO take letter-thickness into consideration.  With me?

IF you used this method... there is no more reason for writeVertical.  Users could do it with the 3d kern feature.  And no reason for writeBackwards, either.  And, writeDiagonally is easy, too. 

We might see a time when there is textFacingDirection and letterFacingDirection.  For example, a textFacingDirection might be v3(.5, .5, .5) (seriously-diagonal word-write direction)... but if letterFacingDirection was something like v3(-.5, -.5, -.5), then each letter would be upright, un-rotated, and facing the z-looking cam... even though the entire word was written at a severe angle.  I have something incorrect, there... but... I think you understand what I seek.  If a word's facingDirection is an odd angle... then user MIGHT still want each letter... to be upright and un-rotated... for easy reading.  Not sure how to accomplish that feature.

All in all, (text)FacingDirection is still needed ... possibly an SPS-only thing, but the 3d kern must take its "rotation" into consideration.  Kerns are in text localspace, but the facingDirection is worldSpace... like the parent of 3d kern.  Does any of this make sense?  I could certainly rock a system that worked this way. 

Share this post

Link to post
Share on other sites

I think you and I have pegged the needle on opposite sides of the creativity scale.  I might steal.

Illuminated Cities are a rectangle floating on sky-texture.  Everything goes on the rectangle for now . . . except when I did this, ( I rotated the date numbers for y'all to see them.  For me, a radical departure.  It then occurred the me that the "low wall" around the city rectangle could hold useful information.  I don't think I will try a circle but I am keeping it in mind.

In other news, Helvetica does not yet support single and double quote but I will add them.

Share this post

Link to post
Share on other sites

Yay, finally got that chrome-like reflecto-shader fired-up on the text.  Coooool.  wheelPrecision and minZ set REAL LOW, so mousewheel-in and check out the hi-rez fractal-pic (refMap).

Slide-around with control-drag, of course.   Awfully danged pretty.  The texture MIGHT need a 50% vOffset or something.  More fractal patterns seen when text is viewed from ends... than when viewed head-on (after animation completes).  Panorama version #55 definitely has a texture mapping issue.  Still looks cool, though.  Studying.   #56 is nice, too... had to set the pivot point to boundingbox center.

Internet Explorer highly-dislikes this... ()=> lines 170 &171.  So, here's a version that works for IE.  (I probably have some compatibility mode incorrectly set in my IE.)

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.