Deviation Actions

greenhybrid's avatar

redshift logo

By greenhybrid
1 Favourite
33 Comments
4K Views
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.
Image details
Image size
800x400px 348.1 KB
Published:
© 2009 - 2021 greenhybrid
Comments33
Join the community to add your comment. Already a deviant? Log In
I love this! I'm using it to inspire an online management team as far as logo and design goes. What font is that?
kram1032's avatar
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
greenhybrid's avatar
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).
kram1032's avatar
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
greenhybrid's avatar
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!
kram1032's avatar
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....
greenhybrid's avatar
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 ... :/
kram1032's avatar
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:
greenhybrid's avatar
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)
View all replies
kram1032's avatar
O.o That's a great idea! :D
greenhybrid's avatar
Which idea? The pleiades one?
kram1032's avatar
int-precision ;)
lyc's avatar
nice logo work :D that's something i find especially difficult!

oh and do tell more about the rewrite... :sherlock:
greenhybrid's avatar
Okay. Some first thoughts, maybe my next ray tracer will be integer based: [link]
lyc's avatar
as was mentioned in the thread, should rather use doubles ;) this is especially true on a nice new 64bit computer.
greenhybrid's avatar
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!)
lyc's avatar
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
greenhybrid's avatar
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
lyc's avatar
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?
greenhybrid's avatar
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".
View all replies
greenhybrid's avatar
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])
lyc's avatar
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 ;)
Join the community to add your comment. Already a deviant? Log In