Ring object

Started by TheBadger, January 04, 2014, 04:58:00 AM

Previous topic - Next topic

TheBadger

Hello

Not sure if there is a bug here, or if things are how they are supposed to be, but here it goes.

I have been playing with a ring object, I am attempting to use it as a sort of control object/null object. As the ring object allows for placement by both position in space, and axis.

Issue 1)
The disk object's Axis parameter is unlike the area rotation parameter of other TG objects, for example, the rock object population.

So if you make a population of rocks and form them into a shape; a square or a circle, and then "tilt" that shape. You cannot simply copy the "area rotation" settings and copy them to the axis setting of the ring and have the same results. For example a setting of -15, 0, 20, copied from the rock population to the ring object, will not give the same results.

Why?

Issue 2)
The ring object when viewed in the 3D preview window does not appear solid at any time and often completely disappears, regardless of where the sun is. Attempting to place the ring relative to something else is hard.
In this image you see the ring in its most compleate form while the camera is steady, however, when moving the camera in 3D preview, the ring may appear sold at times.:
[attach=1]
Why?

Issue 3)
The inner and outer radius of the ring object does not function the same as the simple shape shader radius. For example, if you have two simple shapes, one representing the inner radius of a ring and one representing the outer radius of a ring, you can not copy those radius' to the ring and get a ring of the same size/radius

Why?


Thanks.
It has been eaten.

jo

Hi Michael,

I presume you're talking about a disc object.

1) The Axis parameter of the disc is a vector which defines which way is "up" for the disc. Think of it being like a dinner plate, where the axis is a line going from the centre of the plate straight up, or perpendicular to the plate. Essentially it's the normal of the disc. To change the orientation of the disc you change the direction of the Axis vector. It's not the same as rotation.

I might see if we can add a rotation parameter. I think the axis can be very hard to visualise and it's certainly not very easy to use for orientation.

2) The reason the disc sometimes disappears could be because it's a single sided object. When it disappears you're looking at it from "behind". The next release should have better previews for the built-in objects in the 3D Preview. For example the disc will draw a wireframe and you can see it from all angles, even if the disk itself doesn't show due to the way you're looking at it. You also don't have to wait for it to render before you see it in the preview.

We should probably also make the disk double sided.

3) The Simple shape shader doesn't use a radius, you set the overall size of the shape using the Size parameter. If you're making a circle it's more like setting the diameter. For example you make a circle by setting the Size to { 1000, 1000 } and you get a circle which has a diameter of 1000m and therefore a radius of 500 m.

Regards,

Jo

TheBadger

1) Thank you

2) Yes to all of that, and thank you.

3) Ahhhhhh, I see. THank you!
It has been eaten.

Dune

You could also populate the rocks on a heavily displaced large planet, not near 0/0/0, but more towards the equator, so you'll get an angle to the terrain. And then render without the planet. You could still use the 'ring' made of SSS's, although you might have to shorten one end to even out the distortion due to getting down towards the equator if you get my point.

TheBadger

Hi Ulco. Its not about the rocks. I understand those just fine now.

I am trying to adapt the disc object to use as a null, or control object, like the cube in AE, or the rings in MAya for animating. That is not all Im playing with, just one of the things Im trying to play with. The Disk object seems to be good for this. So For much more than rocks.

It would be nice if we could place atmos apart from the need for a planet object. That is, this idea that you make a planet and then make it invisible is a little irritating. I would rather that I could assign a full spherical atmo to any object on its own, including the disc, separate from any planet, hidden or not.

Apart of this request/question above, is why do clouds require that the be associated with a planet anyway? For example, another limitation in this regard is, that even when localized you can not easily tell a cloud how to form. I would rather that once I got my clouds looking the way I like, I could then (under localize) tell them to tilt, rotate,  move, with controls the same as in an object in how they work.

THat is something broader than the disk object, but gives you an idea of what a control object should make possible.

^^ kinda a ramble, kinda a request, kinda a question^^

Hope someone out there understands what Im getting at.
It has been eaten.

TheBadger

Ok, I thought about this a bit, and think I can explain my self just a little bit better. So here goes nothing.

As I said in the OP, I am playing with the disc object in a number of ways. One of which is a null object/control object. Yes I see that TG has a null node. but it is limited in many ways.

The reason I was trying to see what I could get away with, with the disc as a control is that while, yes, the node system does provide a lot of freedom to create. That freedom happens in a series of strictly defined (and not always well explained) rules, the nodes them selves.
What I wanted to touch on was the idea that the rules could be bypassed. or at least, the entire context of those rules could be altered. And the disc object is shapped in a way that lends its self to what i'm doing anyway.

So for example, what would happen if it was added to the disc object, an atmo input? In fact, why not allow the disk, plane and so on, to have the same power as the default planet, within the confines of their simple shapes?

For example, In another thread, I asked about the idea of a planet in the shape of a cube. I was told that getting an atmo cube shaped would be hard at best. Because an atmo is inherently spherical. That response made sense, its true after all. Yes? Yes.
But if a plane object, was on its own, able to have an atmo like the default planet, and you took six of them and formed a cube, then you end up very close to a cube with a cubic shaped atmo. Yeah there would still be a lot to mess with, but the things that need manipulation are now there.
OK OK! Not everyone is going to have much interest in a cube planet from a superman comic book! But look at all that extra freedom! That cube world is just one idea from one person. I have fear of what others in this community could do with more freedom with nodes!

As for the disc object.
Why must a CG atmo always be inherently reality based? For example,  why cant the atmo be programed to happen in a torus that wraps around the disc? Why not?
And if any of that were possible than just as a planet can be placed in or around another, and then made invisible. couldn't also the simple objects? And what kind of control would that add to something like clouds?.. That is, where all the nodes used to build up any kind of cloud scape you can think of, land in a single "end node" that allows for full control over all position and orientation of the clouds, separate and apart from the default planet (in terms of what controls the clouds, and where there nodes connect to)... As a null object should do. Or at least as null objects do in other soft that I have used.

^^ how about meteorites? If you don't like the other examples. A rock object, for my last example, that has its own clouds! Thats basically what I did here in AE. But rather than a rock (which would have been better) I just used the "null": https://vimeo.com/24949961
And after seeing Hannes asteroid video and a number of TGCs TGDs in the forum, really think this could be a good simplifier.

Now just a word on the idea of reality, in the context of my examples above.
To the best of my knowledge there is not, and never will be a cube planet in our universe. Yes I do really accept that, as mush as it pisses me off.
But I don't, my self, use terragen to recreate reality so much as use it to make fantasy believable. Usually that means making something reality based and simply putting it in a fantastical context. But even when you stay with-in reality completely, who is going to complain about more freedom to create, with more control over what is created?

I realize I jumped around in this post a bit. I hope that you guys will forgive the mixing of ideas. But just to be clear this post and thread are related to actual TG projects that Im playing with, where I find the conventions in the forum don't quite make what I want possible. Or make them really hard and time consuming.

So there you have it.

Thanks for reading.
It has been eaten.

Oshyan

#6
Here's the thing, and it's what underlies a lot of both TGs strengths and weaknesses: you cannot have unlimited flexibility without high complexity *and* you also cannot have fastest-possible render time with unlimited flexibility. The reason for this is that limitations let the software know about shortcuts it can take (or rather, the programmer knows the "bounds of the problem space" and can optimize the code to "look" in that limited area accordingly).

Think about the extreme example, if you wanted software that could calculate the entire galaxy, or even the universe. But let's say most users only want to make a single planet, or maybe two. In order to get that universe-calculating capability, you have to always *consider* and *calculate* the entire universe - how does the software know otherwise if there *is* anything over there? You could have manual limits setup by the user, this is similar to Cloud Localization, and it's why that can help improve render times (because the renderer knows that there will be no cloud outside the localization area, so it doesn't need to check). You could also try to be clever and semi-automatically figure out some boundaries. But ultimately the cleverness takes processor time too. So you lose speed for flexibility. You also increase complexity because there's just no way to express, describe, and control "unlimited capability" without high complexity, if not "unlimited" complexity.

So, there are always trade-offs. Terragen has a spherical atmosphere model because it's a known mathematical system, we know how the Earth atmosphere works and thus how it should be represented. A square atmosphere would likely work very differently, at least in some respects, and at the least it would require some different assumptions in the renderer. As it is, the renderer can probably ignore or greatly simplify calculations beyond a certain distance, or over the horizon. In a square atmosphere, you could be looking off to the horizon, all the way to the other edge of the atmosphere, and *through* a ton of other atmosphere, but one part of the atmosphere would have its haze perpendicular to a "level" camera (level with the planet's surface), and one part would have it parallel to the camera. How does that interact? We need special models to figure it all out, and we're able to optimize less because we can make less assumptions. At the very least we have to make a special atmosphere model to deal with a square shape, or other shapes in general. It takes time and effort to consider such extreme non-standard situations, and while it's great to enable that flexibility, it must be asked: what cost? What cost to render times and ease of use? What cost to development time? etc.

So, next time you're wondering why some crazy, random, cool, interesting, unusual, powerful, awesome feature, capability, option, or setting isn't available, consider what it might take to actually make it possible. Consider that doing so might *necessarily* make other things you do harder, or slower, or it might require more steps to achieve. There are always trade-offs. If we could just make an unlimitedly flexible and capable system that would render in reasonable time, we would! That would be awesome. So far we haven't figured out how, but if we ever do, I think you'll see us making quite a big deal out of it. ;)

- Oshyan

TheBadger

lol, yeah I suppose you would at least make a Sticky!

But its interesting what you wrote Oshyan. And hard to argue. My only question is If nodes are individual pieces of set and defined information, why cant the information in the one be added to the other? So for example if all that was being asked is that the same sphere atmo of the default planet, be given to the disc, would that require the same intensity of labor?

I mean when one node is connected to another, the result is something that neither one alone can do. But what you are saying is that programing a node is not like using one? So just because I can take two nodes and make a new 3rd result, does not mean that you can program the first node to already have the abilities of the second node. Is that right? You cant simply cut and paste a part of one node into another, to put it simply?

If so, thats kinda sad. I did not think that writing code was always from zero. I have very limited experience with writing code, basically none really. But I did learn HTML a long way back and Im working with mel now. And I can cut copy and paste lines just like here. ONly the language is different. So I thought maybe in essence all code is similar. That is, not requiring redoing everything every time you start something new.

I say that because I have on a few occasions seen nodes posted in the forum in text format, I wondered if individual users could make edits to the node functions. Like a mel or python script in Maya.

Its good to know more about it Oshyan, thanks for taking the time. It is more than a little interesting to me, but I guess it can only be academic.
It has been eaten.

Oshyan

Hmm, it's not that easy to explain unless you understand a bit more about 3D rendering in general, and programming as well. I think there is also somewhat of a difference between what you're saying and what I think you mean or intend. For instance, the example you gave, of an atmosphere on a disc, that's not really "programming the node to have the abilities of the other", it's making one node - the atmosphere - work in a way that is compatible with a node it wasn't designed to work with. The basic workings of the atmosphere are designed around a spherical model; changing the atmosphere to work with non-spherical models is possible, but has challenges and drawbacks, and would take a good amount of effort.

When you talk about "coding from scratch" for new nodes, well yes and no. If there are capabilities of one node that are significantly shared by another, for example the Distribution Shader and the Surface Layer (see: altitude/slope restrictions), this kind of stuff can somewhat be re-used, referenced (in code), or at least adapted. But that is a literal "mirroring" of settings, or very similar ones. What you're referring to, I think, is something like "Hey, the planet works with the Atmosphere shader, so why can't we copy what makes the planet work with atmospheres and paste that capability into the disc", and that's not really how it works. I mean yes, you could make the atmosphere connect to the disc node, and maybe even have an atmosphere positioned *in a sphere shape* around the center of the torus, but I don't think that's what you want; essentially that would just be using the torus as the "anchor" or "center point" for the atmosphere rather than a planet. But if you want the atmosphere to literally follow the contours of the disc, *that* is something that needs to be changed *in the atmosphere*, not in the disc! You're talking about *new* capability *for the atmosphere*, not for the disc. So you see perhaps it's not quite as you image, or at least not always.

It's like how some nodes output Displacement, others output Color, others output a single number; some nodes don't do anything with some of that input, for one common example the Power Fractal outputs displacement *along with* color, but many nodes that you use it with - with clouds as a density shader for one - don't do anything with the displacement output, they don't have any functionality that lets them interpret and make use of that data. And you couldn't simply copy code from the Planet or some other node that *does* handle displacement and paste it into the cloud shader and expect it to work.

- Oshyan

TheBadger

One node to rule them all, Oshyan.
I know you guys have it hidden away someplace. Too powerful for us little folk! Too much awesomeness for the average user? Let us see it Oshyan . GOlem! GOlem!

Give me the Precious!

It has been eaten.