Difference between revisions of "Talk:Main page"

From BRL-CAD
m (Reverted edits by MpexCorporation (talk) to last revision by Sean)
 
(21 intermediate revisions by 13 users not shown)
Line 1: Line 1:
[http://www.liquidleds.com.au/ LED light bulbs] are often touted as the future of lighting, but should you really buy into all the hype? With all the claims you hear about LEDs being the perfect replacement to incandescent and compact fluorescent bulbs, when should you make the big switch to LED lighting? We hope this article clears up some common misconceptions about LED lighting, and reaffirms doubts about what makes LED light bulbs so great.
+
Hello and welcome, X Tin Basher!  The edits to EBM and elsewhere are more than welcome, thanks!
  
Here are 5 facts you should consider when thinking about switching to LED light bulbs.
+
Cheers! --[[User:Sean|Sean]] 10:48, 23 November 2010 (EST)
  
1. LEDs were first designed give off directional or focused light
+
----
  
Early prototypes of LED light bulbs were designed to give off directional light. Unlike incandescent and CFL bulbs, LEDs were considered to be poor choices for lighting large areas. However, this has all changed today, with various types of LED bulbs specifically designed for lighting large spaces, such as hallways, arenas, and more. The directional limitation of LEDs has been solved through innovation and persistence.
+
I've started having fun with BRL-CAD, but I notice that this wiki needs some TLC. I'm an old hand at mediawiki, so if nobody objects, I'm going to start making massive changes here. For starters, I can:
 +
* categorize every page, looks like there's quite a few untagged pages
 +
* relabel the stuff in [[:Category:MGED]] to remove the prefix so it looks nicer (this is a huge job unless it gets automated)
 +
*Eventually, I'd like to make a page for (almost) every executable in brlcad/bin; some already have pdfs or pages and I'd start by finding and categorizing these.
  
2. LEDs typically generate blue light
+
If there are no objections, I'll get started when I have time. --[[User:Ssd|Ssd]] 08:40, 12 November 2009 (EST)
  
Most LED light bulbs that are sold in the market today generate blue light. However, many manufacturers are now making steps to produce light bulbs that emit white, warm and cold light, so this shouldn’t be a problem anymore. Still, it pays to test a light bulb and be aware of its colour before making any purchase.
+
----
  
3. LEDs have a problem with heat
+
Hi Ssd, no objections whatsoever!  The wiki could absolutely use lots of TLC. Let me know if there are things I can do to help you out.  If you're really up for a challenge, one of the things we were working on over a year ago (that never got off the ground) was a way to keep our Docbook XML sources fully synchronized with Mediawiki so you could perform bidirectional editing and have changes to one update the other.  The basic idea was a Mediawiki plugin that staged wiki changes to an SVN checkout with Docbook-to-wiki and wiki-to-Docbook conversions happening on the fly.
  
Thermal management has always been a problem with LEDs. Excessive heat drastically reduces the life span of an LED light bulb, which can make it a poor choice for outdoor lighting. When installing LED light bulbs, be sure not to place it near a heat source.
+
Something to perhaps think about, but even without that, the Wiki still needs massive TLC. The categorization and filling in of missing content will be greatly appreciated!
  
4. Some LEDs are not dimmable
+
Cheers! --[[User:Sean|Sean]] 08:48, 12 November 2009 (EST)
  
As of writing this article, there are already a number of fully-dimmable LED light bulbs in the market which work just like traditional incandescent bulbs. More research is done to perfect the design of these LED bulbs, so if you’re a perfectionist who wants permanent designs, you might want to wait for better versions in the future.
+
----
  
Although ordinary LED light bulbs will work in sockets with a built-in dimmer, this is not recommended, as it can shorten a bulb’s lifespan, or worse, cause it to burn out completely.
+
It also annoys me that none of the PDF's have a table of contents, but that's not somethign I know how to fix so easily. --[[User:Ssd|Ssd]] 09:02, 12 November 2009 (EST)
  
5. Lumens ratings are often unreliable
+
----
  
Lumens is the strength of light as perceived by the human eye. With light bulbs, it’s measured using a device that takes the average brightness a bulb generates. You may have heard of comparisons between a low-energy LED light bulb and a 50-watt incandescent bulb, but bear in mind that LEDs focus their light in one spot, while incandescent bulbs are multi-directional. One 50-watt incandescent bulb can light up a small room; an LED bulb on the other hand, does this poorly.
+
Lots of great updates earlier today!  As for the table of contents, are you referring specifically to PDF indices?  Otherwise, the big documents (Vol II - Intro to MGED and Vol III - Principles of Eff. Modeling) have tables of contents (on pages vii and iii respectively).  They're also part of the larger migration to Docbook as the central document management format so that the PDF files can be continually updated and regenerated, and the documents can be output in different formats (e.g. directly integrated with the wiki or even if just as static html dumps). -- [[User:Sean|Sean]] 15:26, 12 November 2009 (EST)
  
The old standard of measuring lumens may put a low-energy LED light bulb at par with a 50-watt incandescent bulb, but this doesn’t take into account the unique way in which LEDs display their light. Your best bet is to do a side by side comparison between an incandescent, CFL, halogen and LED light bulb to see which one fits your needs.
+
:Lots of updates...yes, and did you see the time frame?  Those were the easy ones.  The rest will take longer, especially as I might actually have to write and/or research the content.  As to the PDF's...the document has a toc obviously, but the PDF does not.  Yes, I mean the pdf toc/index/bookmark thingie.  Very annoying to try to find stuff in there without one.  I take it that the docbook material is not yet in the wiki. Has anyone started work on a wiki translator for it?  The bidirectional gateway thing sounds interesting but dangerous. --[[User:Ssd|Ssd]] 00:58, 14 November 2009 (EST)
 +
 
 +
== BRL-CAD Primitives ==
 +
 
 +
I got annoyed that I couldn't find a comprehensive list of primitives, so I started filling out [[BRL-CAD Primitives]].
 +
I'm sure I missed a few, and the few that are there don't all have complete information.
 +
It would be nice to add a description/title, and a link to relevant documentation (and page) for those that need it.
 +
 
 +
Anyone wanna help fill in the blanks?  --[[User:Ssd|ssd]] 05:39, 31 December 2009 (EST)
 +
 
 +
:Of relevance to this work, there is http://brlcad.org/tmp/primitives/ which includes grouping and visuals for most of the production-ready primitives. --[[User:Sean|Sean]] 14:20, 25 March 2010 (EDT)
 +
 
 +
I suggest utilizing this work for categorization of primitives - we've been working on how to group these things for a while, and we have an ordering that's based on a combination of the mathematical nature of the primitives and the type of data they use:
 +
 
 +
http://bzflag.bz/~starseeker/geometric_primitives.txt
 +
 
 +
CY (starseeker in irc)
 +
 
 +
Note that this categorization doesn't include a few "work in progress" primitives like metaballs and superell - metaballs in particular might need a little thought to categorize it - perhaps composite implicit
 +
 
 +
:Great stuff!  So brl-cad DOES have a revolve primitive!  I'll have to play with that I guess.  I still hate the sketch editor, so unless I start importing sketches, I might just stick with pipes.  I added a few more from your list to the list. Your categorization closely fits mine already.  A few discrepancies...  First, in what way is a halfspace polyhedral?  It doesn't even seem bounded.  Also, I can't find support for sweep or brep.  I assume they aren't supported in my version.  (Do we need to tag new primitives with version numbers?) Also, a lot of your "hard to categorize" things I just stuffed in an "other" category; although the order I put them in still groups them about the same as you do, even within the other group.  --[[User:Ssd|ssd]] 17:10, 31 December 2009 (EST)
 +
 
 +
How about a category for meshed primitives?  This would include (please correct me!) ars, bot, spline, nurbs, and maybe metaball?  --[[User:Ssd|ssd]] 01:58, 1 January 2010 (EST)
 +
 
 +
:The only truly meshed primitives are the BoT and NMG primitives.  ARS is presently implemented as a polygonal surface, but that is mostly an implementation detail (it could just as easily be a NURBS surface).  Similarly, spline, nurbs, and metaballs aren't meshed.  With the exception of metaballs, all the rest have one trait in common in that they are primitives with an explicit boundary representation.  Metaballs are an implicit boundary representation primitive.  --[[User:Sean|Sean]] 14:20, 25 March 2010 (EDT)
 +
 
 +
Hello Sean. Glad I haven't upset anyone yet with my edits. I'm a bit OCD about English grammar. Don't expect any amazing code or anything similar from me; I'm an ex-mechanical engineer, and computer programming is definitely not my forte. Nor am I mathematically gifted. But, BRL-CAD seems to fit my needs for a combined Cad-Modeller-Renderer. Bit of a steep learning curve, though...

Latest revision as of 15:24, 21 September 2018

Hello and welcome, X Tin Basher! The edits to EBM and elsewhere are more than welcome, thanks!

Cheers! --Sean 10:48, 23 November 2010 (EST)


I've started having fun with BRL-CAD, but I notice that this wiki needs some TLC. I'm an old hand at mediawiki, so if nobody objects, I'm going to start making massive changes here. For starters, I can:

  • categorize every page, looks like there's quite a few untagged pages
  • relabel the stuff in Category:MGED to remove the prefix so it looks nicer (this is a huge job unless it gets automated)
  • Eventually, I'd like to make a page for (almost) every executable in brlcad/bin; some already have pdfs or pages and I'd start by finding and categorizing these.

If there are no objections, I'll get started when I have time. --Ssd 08:40, 12 November 2009 (EST)


Hi Ssd, no objections whatsoever! The wiki could absolutely use lots of TLC. Let me know if there are things I can do to help you out. If you're really up for a challenge, one of the things we were working on over a year ago (that never got off the ground) was a way to keep our Docbook XML sources fully synchronized with Mediawiki so you could perform bidirectional editing and have changes to one update the other. The basic idea was a Mediawiki plugin that staged wiki changes to an SVN checkout with Docbook-to-wiki and wiki-to-Docbook conversions happening on the fly.

Something to perhaps think about, but even without that, the Wiki still needs massive TLC. The categorization and filling in of missing content will be greatly appreciated!

Cheers! --Sean 08:48, 12 November 2009 (EST)


It also annoys me that none of the PDF's have a table of contents, but that's not somethign I know how to fix so easily. --Ssd 09:02, 12 November 2009 (EST)


Lots of great updates earlier today! As for the table of contents, are you referring specifically to PDF indices? Otherwise, the big documents (Vol II - Intro to MGED and Vol III - Principles of Eff. Modeling) have tables of contents (on pages vii and iii respectively). They're also part of the larger migration to Docbook as the central document management format so that the PDF files can be continually updated and regenerated, and the documents can be output in different formats (e.g. directly integrated with the wiki or even if just as static html dumps). -- Sean 15:26, 12 November 2009 (EST)

Lots of updates...yes, and did you see the time frame? Those were the easy ones. The rest will take longer, especially as I might actually have to write and/or research the content. As to the PDF's...the document has a toc obviously, but the PDF does not. Yes, I mean the pdf toc/index/bookmark thingie. Very annoying to try to find stuff in there without one. I take it that the docbook material is not yet in the wiki. Has anyone started work on a wiki translator for it? The bidirectional gateway thing sounds interesting but dangerous. --Ssd 00:58, 14 November 2009 (EST)

BRL-CAD Primitives[edit]

I got annoyed that I couldn't find a comprehensive list of primitives, so I started filling out BRL-CAD Primitives. I'm sure I missed a few, and the few that are there don't all have complete information. It would be nice to add a description/title, and a link to relevant documentation (and page) for those that need it.

Anyone wanna help fill in the blanks? --ssd 05:39, 31 December 2009 (EST)

Of relevance to this work, there is http://brlcad.org/tmp/primitives/ which includes grouping and visuals for most of the production-ready primitives. --Sean 14:20, 25 March 2010 (EDT)

I suggest utilizing this work for categorization of primitives - we've been working on how to group these things for a while, and we have an ordering that's based on a combination of the mathematical nature of the primitives and the type of data they use:

http://bzflag.bz/~starseeker/geometric_primitives.txt

CY (starseeker in irc)

Note that this categorization doesn't include a few "work in progress" primitives like metaballs and superell - metaballs in particular might need a little thought to categorize it - perhaps composite implicit

Great stuff! So brl-cad DOES have a revolve primitive! I'll have to play with that I guess. I still hate the sketch editor, so unless I start importing sketches, I might just stick with pipes. I added a few more from your list to the list. Your categorization closely fits mine already. A few discrepancies... First, in what way is a halfspace polyhedral? It doesn't even seem bounded. Also, I can't find support for sweep or brep. I assume they aren't supported in my version. (Do we need to tag new primitives with version numbers?) Also, a lot of your "hard to categorize" things I just stuffed in an "other" category; although the order I put them in still groups them about the same as you do, even within the other group. --ssd 17:10, 31 December 2009 (EST)

How about a category for meshed primitives? This would include (please correct me!) ars, bot, spline, nurbs, and maybe metaball? --ssd 01:58, 1 January 2010 (EST)

The only truly meshed primitives are the BoT and NMG primitives. ARS is presently implemented as a polygonal surface, but that is mostly an implementation detail (it could just as easily be a NURBS surface). Similarly, spline, nurbs, and metaballs aren't meshed. With the exception of metaballs, all the rest have one trait in common in that they are primitives with an explicit boundary representation. Metaballs are an implicit boundary representation primitive. --Sean 14:20, 25 March 2010 (EDT)

Hello Sean. Glad I haven't upset anyone yet with my edits. I'm a bit OCD about English grammar. Don't expect any amazing code or anything similar from me; I'm an ex-mechanical engineer, and computer programming is definitely not my forte. Nor am I mathematically gifted. But, BRL-CAD seems to fit my needs for a combined Cad-Modeller-Renderer. Bit of a steep learning curve, though...