|
|
| |
Brick Your iPhone4
This may be the one case to rule them all for LEGO geeks everywhere.
Have a Apple iPhone4? Want a new case for your iPhone4? Tired of not able to
build with your phone?
For Apple and LEGO Geeks in the world.
Wired.com
The main website is smallworks.com.
FYI: The case will work with the AT&T iPhone4. Reports from other web sites
regarding to iPhone4 there is a slight design change to the phone. This has to
with the new iPhone4 from Verzion. Before you buy make sure you have the right
iPhone.
|
|
| |
In lugnet.off-topic.geek, Manfred Moolhuysen wrote:
| |
In lugnet.off-topic.geek, John Neal wrote:
| |
Well, when I was young, we didn’t have fancy-schmancy comPUters. We had to
use rocks for all of our computations. And it took all day to collect enough
rocks to multiply 12x12 and our hands would get all bloody from hauling
rocks around all day, and we LIKED IT. We loved it.
|
Mmm-mmm, Stonehenge was a VERY advanced calculator, for it’s time...
|
LOL Stonehenge!! Good one, Manfred!
I have heard of
Duncan’s
handiwork before!
:-)
JOHN
|
|
| |
In lugnet.off-topic.geek, John Neal wrote:
| |
Well, when I was young, we didn’t have fancy-schmancy comPUters. We had to
use rocks for all of our computations. And it took all day to collect enough
rocks to multiply 12x12 and our hands would get all bloody from hauling rocks
around all day, and we LIKED IT. We loved it.
|
Mmm-mmm, Stonehenge was a VERY advanced calculator, for it’s time...
|
|
| |
In lugnet.off-topic.geek, Anders Isaksson wrote:
> Tore Eriksson wrote:
>
> > My first PC had no hard drives, just two 360 kb floppy drives. One
> > for the OS and the other for applications and documents. My second PC
> > had a 10 Mb hard drive that took the physical space of two 5 1/4"
> > drives. The Michelangelo virus took its real-time clock app...
>
> But that was a long time ago :-)
>
> Nowadays we *do* have an awful lot of disk space, and don't really have to
> squeeze the files.
>
> OTOH, every 'unnecessary' byte to read will take time, again and again while
> rendering, unless the rendering program is compiling the .dat file into some
> internal representation at the first read.
>
> OTTH, I believe all the programs do this, the original LDRAW.EXE being the
> exception (possibly, I don't have the source).
>
> So, I would view overlap as an error.
I'm not worried about disk space so much as I am worried about render/move/edit
time. Unnecessary polygons, even after being read in and converted into internal
models, take time to process. I think you can see the difference in POVray
render times, for example... even if the part was compact on disk because it
uses nested submodels, it might blow out to a lot of polygons that need
clipping/raytracing/texturemapping and thus slow down render time.
So:
* Things that cause artifacts - very bad
* Things that add polygons that don't add to the image quality - bad
* Things that add polygons that do add quality - it depends, probably good
(especially if you can turn them off for fast renders when doing tests)
IMHO anyway. YMMV
(is this FUT right? shouldn't this be in CAD somewhere. moved it to lugnet.cat)
|
|
| |
Tore Eriksson wrote:
> My first PC had no hard drives, just two 360 kb floppy drives. One
> for the OS and the other for applications and documents. My second PC
> had a 10 Mb hard drive that took the physical space of two 5 1/4"
> drives. The Michelangelo virus took its real-time clock app...
But that was a long time ago :-)
Nowadays we *do* have an awful lot of disk space, and don't really have to
squeeze the files.
OTOH, every 'unnecessary' byte to read will take time, again and again while
rendering, unless the rendering program is compiling the .dat file into some
internal representation at the first read.
OTTH, I believe all the programs do this, the original LDRAW.EXE being the
exception (possibly, I don't have the source).
So, I would view overlap as an error.
--
Anders Isaksson
|
|
|
