Shop Mobile More Submit  Join Login
redshift logo by greenhybrid redshift logo by greenhybrid
Again played a bit with the gimp to create this fancy logo for the new rendering kernel of picogen (as gtalked with lyc, about the quasi-rewrite).

Nothing spectacular. I used a free NASA image of the Pleiades (see wikipedia entry for "star" if curious) as the background.
Add a Comment:
 
:iconcanucks357:
canucks357 Featured By Owner Jun 9, 2011
I love this! I'm using it to inspire an online management team as far as logo and design goes. What font is that?
Reply
:iconkram1032:
kram1032 Featured By Owner Feb 8, 2009
btw: an int205,266.889.319.213.380.056.866.320.664.091.969.
283.649.733.145.103.409.242.357.675.883.593.110.850.520.
558.487.785.500
(which obviously is a floatingpoint integer xD) would be enough to simulate the visible universe in planck-lenghts!
So, an int256 would go FAR beyond quantum size O.o
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Feb 12, 2009
absolutely!
The nice thing is, having a much much much (MUCH!) larger range at lot lot lot (LOT!) finer grain is just a few cpu instructions away. Especially because I will only need addition and subtraction for those large types (for translating objects into local space, where I then can switch to floating point types) (at the moment I am relatively sure that any artifact shouldn't be too noticeable for long ray lengths).
Reply
:iconkram1032:
kram1032 Featured By Owner Feb 12, 2009
wait... would that be like global positioning (like... center) with int-precision and then, local positioning (the actual shape, based on center) with float? or how or what? ^^

Really a great idea and I can't wait to see extreme test results :D
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Apr 17, 2009
Not exactly, I seriously thought about a hierarchical approach as you mention; but I decided to take a more simplicistic approach:

Actual points (as in the positions of a polygon, or the center of a sphere) are int64. Directional information (called Vectors and Normals in picogen) are floatint point.

On the other hand, I am not saying "never" about the hierarchical approach. Once picogen:redshift wants to live up to it's name, int64 won't be enough. On the third hand, int128 or int256 could still be faster then hierarchies .... Time will tell!
Reply
:iconkram1032:
kram1032 Featured By Owner Apr 19, 2009
ah IC :) That's a nice one. It would be hard to do unit-vectors with int... :nod: I guess, that approach already is perfectly fine :nod:
As I mentioned before: Int 256 would be sufficient to make the whole universe in planck-lenghts :lol: And that also shouldn't be such a problem for today's RAM and co....
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Apr 21, 2009
wonderfull. int256 should be superior in performance compared to hierarchical spaces.

with whole universe, do you mean the visible universe? because someday, the picogen renderer "redshift" shall live up it's name :D

hmm, then what remains is how to simulate a branching universe inside a multiverse of branching universes ... :/
Reply
:iconkram1032:
kram1032 Featured By Owner Apr 21, 2009
of course the visible one. There is no proofable number for all the other variants.

The multiverses will need a further definition though, like, 4D or higher ;)

All the verses lie in a bigger nD-verse (physicists aren't sure, how many... heard so many variants 'till now xD I wonder what's the most popular one right now...)

Also, for multiverses and co, if you look at the organisation from sub-atomic particles up to multiverses in a fractal way (basically different steps or energy-organisation, in the end), you might get a feel for true physical infinity - aka you'll need infints for that xD

btw, how I calculated it:

2^256 = 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936

according to Wikipedia, the observable universe is (at least) 93 billion lightyears wide, giving you 8.79829142e26 m
the planck lenght is 1.616252457677754134112479120986938602161024299570340768391981149326239172011423107331e-35 m

that gives you 5.44363683916153986558256955253284561149987547345636819647387763841815866649485631321e+61 planck lenghts for the universe - a number, which uses 80.1102283639848214585003874928078361957640324308066140352606767812020598903014473186% of the available digits in a 256int.

Infact, to print out the whole number as int, you'd only need a 206int, but as that's not as nice as 256 (for computers), 256 could under circumstances (due to optimisation options) be faster than 206...

so, you still have a lot of free space for superuniversal scales :lol:
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Apr 24, 2009
yay very cool. thanks for the explanation, mate :D

yeah, that fractal was why i think that i need some growing hierarchy of branching universes, but i guess i am anyways bound by memory limits (i mean epic universal limits here :D)
Reply
(1 Reply)
:iconkram1032:
kram1032 Featured By Owner Feb 7, 2009
O.o That's a great idea! :D
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Feb 12, 2009
Which idea? The pleiades one?
Reply
:iconkram1032:
kram1032 Featured By Owner Feb 12, 2009
int-precision ;)
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Apr 17, 2009
Ah okay :P
Reply
:iconkram1032:
kram1032 Featured By Owner Apr 19, 2009
:)
Reply
:iconlyc:
lyc Featured By Owner Feb 4, 2009
nice logo work :D that's something i find especially difficult!

oh and do tell more about the rewrite... :sherlock:
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Feb 6, 2009
Okay. Some first thoughts, maybe my next ray tracer will be integer based: [link]
Reply
:iconlyc:
lyc Featured By Owner Feb 7, 2009
as was mentioned in the thread, should rather use doubles ;) this is especially true on a nice new 64bit computer.
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Feb 12, 2009
while this is nice for lazy coders like me, it basically just shifts the problem away a bit.

btw, i've started to code up a proof of concept. will take some days. but after i have implemented proper rounding for fixed point typecasting this morning, i think i can go for the real stuff the next day (i.e. ray tracing!)
Reply
:iconlyc:
lyc Featured By Owner Feb 12, 2009
hmm, and using int64 instead of float32 isn't doing the same sweeping-under-carpet? ;)

i still think that you will have *far* better overall precision (and performance) using doubles instead of 64bit ints. well, if you need to see it by experience rather than deduction, i won't rob you of your lesson ;P
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Feb 12, 2009
The main idea is that with fixed-point you can have the same precision everywhere, so I could even do an animation of a flight from neptune to the sun, and inbetween zoom in onto a bunch of ants sitting on a leaf of some small tree on earth. And eeeevery where I have the same absolute spacetime resolution, so it doesn't matter if I locate the sun at (0,0,0) or at (55555.132,321,54) in my next render.

But with floating point numbers, you lose "absolute" precision the further you get away from 0, and it would make a big difference whether I locate the sun at (0,0,0) or at (55555.132,321,54) in my next render.

The nice thing is, for real intergalactic travels (imagine you build up a nice universe for your next MMORPG(GSDFKLHJNSDFKLN)) I just increase the number of bits, and still have the same fractional precision everywhere, but with floats you will get even higher precision where you don't need it (i.e. wasted bits), and just shift the "precision-horizon" further away with each bit.

A little mindplay: I have int64 with resolution 0.00 002. I have a float that occupies the same store of 64bits, with resolution 0.000 000 2. With int64, I reach Neptune and a bit more. Will I also reach it with my float (which has same storage)?

Hmm, maybe I enlighten you with this (yay?!)?

:D
Reply
:iconlyc:
lyc Featured By Owner Feb 12, 2009
hmm, i think you have it the wrong way around, and that's the key to understanding why floating point is so much better for such differing scales than fixed point...

you said: "I just increase the number of bits, and still have the same fractional precision everywhere, but with floats you will get even higher precision where you don't need it (i.e. wasted bits)" -> think about it, specifically your comment about wasted bits!

are you sure you have no wasted bits in a cornell box, stadium and solar system? are you sure that float/double waste bits at any scale?
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Feb 12, 2009
hmm. i am not the most competent to argue in that discipline :D

about the "wasted bits": with a double i can have a resolution of 0.0000000001 (which i (imho) don't really need in a non-unbiased enivronment) or so, *when* a double is small. but for *big* doubles, the resolution gets smaller, say, like 0.1, or if big enough, even bigger than one or two or yet bigger. while the resolution wrt the number of states between any pair of 2^x and 2^(x-1) remains the same, it also follows that the number of states between each natural number y and (1+y) decreases, and gets even much smaller than 1.

so, while on earth you can place your l-system plants (bwaha, when when when) very freely and exactly, it could get a problem to place them exactly on mars, where you than would have to place all plants on a "very" discrete grid. this would be where my wasted bits on planet scale would go.

sure you can use hierarchies, and place your plants relative to the center of mass of mars, but then you also want to place mars relative to the center of mass of the sun, because else mars could move at "very discrete" space-steps, say with a relative move-vector of (0,0,23), where earth will travel at (0,0,0.5). then, you also want to place the camera relative to ... what exactly?

of course, it would be easiest to use doubles and restrict what can be done, and just place the planets onto a cubemap texture. but that will never ge me an award (...) for a nice solar-system animation with a final zoom in on some l-system plant on a bogo-planet. also, using doubles will also restrict me from future increasements, because i am not tbp who can code every double at every precision in every language (including malbolge) :D

tbp provided a super link: [link] , i am pretty sure da will mess up the link, so basically the link is [link] , and then the article "A matter of precision".
Reply
(1 Reply)
:icongreenhybrid:
greenhybrid Featured By Owner Feb 5, 2009
Oh, and I would have nothing against hacks like deferred shading, zbuffering and co.. Just wanted to mention that. (though I will have something against rasterisation as the basetec, so fear not; on the other hand, I would have nothing against point based rendition, if applicable.)

Looks like once again you were right about me writing yet another ray tracer :worker:

(at least I could reuse picogen in future as a general purpose renderer)

Also, I am only 50% happy with the rewrite, as the codebase has reached 20-30 kloc (see [link])
Reply
:iconlyc:
lyc Featured By Owner Feb 7, 2009
i think the real aim should be to *do more* with the software you've written, make it a tool for your explorations rather than trying to build rome ;)
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Feb 12, 2009
hmm. the only idea i have is to reuse the heightmap/skymap/tool-stuff :|
Reply
:iconlyc:
lyc Featured By Owner Feb 12, 2009
btw i tried picogen 1.2, but there were no example scenes :hmm: seriously, how about a nice 64bit multithreaded windows example someday? ;)
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Feb 12, 2009
really? at home, I have some scenes. will send :D
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Feb 5, 2009
Thanks :) I find it extremely difficult, too. But I love your logo works so far (especially in your specular fractal render, for which I hereby request again a sequel) :D

rewrite: Total specialisation. I am dreaming of something that will take into account the different orders of scale in nature (like you don't have to draw grass carpets when rendering the solar system). Maybe I will also implement the scanline approach for terrain rendition you mentioned once (where you draw from near to far). But actually, I don't have deeper blueprints yet. But the term redshift shalt imply that I no longer want to limit on limited size heightmap terrain :D
Reply
:iconlyc:
lyc Featured By Owner Feb 7, 2009
i suppose you'll get a new fractal render soon, it won't be the mandelbrot but it will be quite interesting ;) the res is a bit inaccessible though, 3840x1200 (dual widescreen)...
Reply
:icongreenhybrid:
greenhybrid Featured By Owner Feb 12, 2009
excellent!
Reply
Add a Comment:
 
×




Details

Submitted on
February 1, 2009
Image Size
348 KB
Resolution
800×400
Link
Thumb

Stats

Views
3,591 (2 today)
Favourites
1 (who?)
Comments
33
Downloads
104
×