This is very simple as you will see.
I have several progressions into other things like distorting the strata but I'm not happy with that yet. There are ways to easily distort the strata but not the way I want to do it.
By the way, many of my nodes will have abbreviated names. This is because when I have complex planets I like to keep the names short or the graphs get a mess. In the above case, I renamed the get altitude because that is the crucial technique here or if the node is a major component to edit I will name it for what it does. I might tidy this system up further in future.
Yes it is a pity, that Matts reserves the joy of making functions for himself.
Here is one way to distort the strata:
Another method. Completely different distortion technique:
Next solution (possibly final).
See Matt about the nasty shadows on distorted displacements. Also, you'll see large rendering of hidden material if you render this file. This happens to large extent on many POVs I use.
Where's the nasty shadow? There is some roughness due to micropolyons not being smaller than a pixel, is that what you mean?
Matt
Matt, I think what he is calling a 'nasty shadow' is the rough look of the shadows beneath the smooth perlin curves. It is a little rough. It might be a result of too few samples of the atmosphere, or soft shadow samples.
Hi matt. I've seen this shadows thing before. It crops up in virtually every render to some extent. It's not so noticeable in these renders but if you distort the displacement around a lot then shadows get jagged effects.
Also, it would be great if the renderer was able to cut out all the excess rendering that sometimes goes on i.e. beyond horizon. I don't know what the plans are with this kind of thing but sometimes on a big render there is stuff rendering for hours that isn't in the final render. It seems to crop up on specific planets and POVs like say a planet with large flat areas and a higher POV. I'm about to post another technique in another thread. If you look at this new one, it does not have the problem. At least from where the POV is taken from.
The shadows may of course not be the problem. It might be coming from the geometry. I don't know. I haven't experimented to full with it yet. I understand that stretching geometry around is maybe going to create problems. If you do this to huge extend in Mojoworld you can get jagged polygon shapes but it needs to be really huge distortions.
Actually the new render I'm doing now does seem to be working on stuff not appearing. I just can't see it. It's delaying for ages with no changes meaning it's doing the same thing. I don't know what kind of optimizations are going to happen in future but there are clearly hours wasted on bigger renders.
I just ran a test. You can reduce the nasty jagged shadows by switching on microvertex jittering.
Quote from: efflux on August 03, 2009, 05:13:34 PM
Also, it would be great if the renderer was able to cut out all the excess rendering that sometimes goes on i.e. beyond horizon. I don't know what the plans are with this kind of thing but sometimes on a big render there is stuff rendering for hours that isn't in the final render. It seems to crop up on specific planets and POVs like say a planet with large flat areas and a higher POV. I'm about to post another technique in another thread. If you look at this new one, it does not have the problem. At least from where the POV is taken from.
The problem is that Terragen needs to calculate displacement before it knows whether something will be hidden. If it appears behind something that's already been rendered, it won't calculate any shading, lighting or atmosphere, you can be sure of that. (The only time that fails is when the approximate sorting is inaccurate from certain views.) But it still needs to calculate distant displacement in case it causes the terrain to rise into view, and when it does you need to have high detail.
It is possible to take shortcuts and guess the likelihood of the terrain being visible without fully subdividing, but those optimisations are not 100% robust (although it is possible if I can efficiently scan the depth map over large regions... something for the future perhaps). If you could tell Terragen not to render beyond a certain distance, that would help. Maybe an option I can add to the planet in future.
Matt
Quote from: efflux on August 03, 2009, 06:19:06 PM
I just ran a test. You can reduce the nasty jagged shadows by switching on microvertex jittering.
I'd be interested in seeing those renders.
Matt
OK Thanks. I can see the problem with the displacements. However sometimes this is very extreme - rendering stuff that is well under the distant horizon line so maybe some kind of distance control would be beneficial.
There are probably compromise methods I suppose but it would be bad if any displacements were not rendered. This is an issue with Mojoworld (except with volumetrics). Surface displacements after initial terrain layer all disappear in the distance unless you increase rendering detail to very high. It makes Mojo fast but large displacements are not seen in the distance. It also effects the general surface quality - a rough surface in foreground looks shiny in distance.
I will have to render something again to compare a bad shadow area with one improved when I enabled microvertex jittering because I binned the bad one. TG2 is rendering at the moment. I'll post back here about that.
By the way, Mojoworld spends ages doing a whole bunch of calculations before it even starts rendering. I'm guessing it's doing these various optimizations during that time. The fact that the displacements disappear in the distance is one of my pet hates with Mojo. it ruins anything with any serious overhangs and makes distant objects look typically CG smooth.
This is not a great example and very small but it's enough to show the effect. I might get a better render later and do further tests.
Render setting are:
Detail - 0.8
Antii-aliasing - 3
No GI because this doesn't make any difference to the problem.
Shadows are obviously on since this is when you see the problem.
The picture that has less of the small black dots has Microvertex jittering and detail jittering turned on but I think microvertex jittering is the setting that improves it. I can't confirm that this is always successful. Increasing detail improves things as well. Detail 1 can still exhibit the problem just not too noticeable.
Also, in this particular corner of this rock I did at one time see an odd twisted form under the surface appearing during render. This only happened once at some particular POV and render setting. This terrain is two fractals blended and this line is at the blend but it makes no difference really. Any place where there are any twists or stretches of geometry at sharper angles can exhibit this problem.
I'll set up a better example of this at some stage by having much smoother shapes but stretched then displaced.
Is is just a case that at certain small angles and directions the triangular polygons have a problem creating a nice crease?
these are fascinating and awesome...thanks for sharing your insight!
Quote from: efflux on August 04, 2009, 01:21:00 AM
By the way, Mojoworld spends ages doing a whole bunch of calculations before it even starts rendering. I'm guessing it's doing these various optimizations during that time. The fact that the displacements disappear in the distance is one of my pet hates with Mojo. it ruins anything with any serious overhangs and makes distant objects look typically CG smooth.
Yep. Whether you do the calculations up front, or during the render, they have to be done at some point :) And I made a decision to keep horizon details reasonably high in TG, even knowing that things could be faster if I took the kinds of shortcuts it sounds like Mojo takes. I do reduce detail near the horizon, just not enough that you can really see it happening.
Matt
The only solution to reduce the crinkliness of sharp geometric edges is higher detail settings. It's basically a sampling problem.
Regarding the blotchy shadows, yes they could be fixed by using the same detail in my shadow casting geometry as the visible geometry, but you wouldn't like the render times. Again, increasing detail should reduce their visibility.
Because increasing detail solves various problems, it's better to increase detail and leave some of the other expensive aspects of the renderer at relatively lower details to keep render times reasonable. That way you can increase detail to solve various problems at the same time.
If I make a setting that allows you to adjust relative detail of the shadow casting geometry, everybody will crank it up to 1 for their final renders when they don't need to, making their renders much slower. Sometimes it's better not to give the user too much power. I hope you understand where I'm coming from ;)
Matt
The question of detail is a matter of perception more over it is an artifact of the Human visual system, in real life the amount of detail that can be perceived is dependent on the objective distance in relation too the viewer; that is to say that too the eye there will be more detail on a tree a distance of three feet than one at fifty or a hundred feet away given ideal viewing conditions.
There are many mitigating factors that govern detail and the amount of same that can be observed these include and are not limited too, Age of viewing subject (Visual Acuity decreases with age), Visual Anomalies in the eyesight of viewing subject such as impaired depth perception weather acquired such age, by birth or by other means, neurological particularly degeneration or injury too the Visual Cortex, other factors include line of sight and particularity obstructions between the viewer and the object been viewed, attitude difference between object and the viewer, meteorological phenomena such as fog, time of day and sun angle relative to the observers viewing angle among others.
There is a mechanism in the brain (I do not know its name, for the record) that protects us form sensory overload it acts as a filter preventing us from neurological distress the eye picks up a tremendous amount of detail, that we are not aware of, when absent the detail is missed: this then is the fundamental failing of CGI and why research in the area is ongoing too give our Augmented Reality via various means what nature and the ravages of time give us for free.
It is our artistic wish to capture a moment in time and freeze it for others who'd come after we have all long turned too dust and that dust has been scattered by the winds of ages may get a scene just for a moment of that moment in time. Our ancestors did it with the first cave painting over time the methods changed but the passion to create never has, need we defile their grace that long line of artists who have gone before or do we instead honor them and be thankful for what we have, despite its failings?
All good things come in time, the faults of TG2 are included in this.
Regards to you.
Cyber-Angel ;D
On a side note, you can induce hypnotic trance by overloading the conscious mind, another good reason to have the "Reality Filter®" in place.
cheers, Simon. (going off on a tangent).
Quote from: Matt on August 04, 2009, 08:39:04 AM
Regarding the blotchy shadows, yes they could be fixed by using the same detail in my shadow casting geometry as the visible geometry, but you wouldn't like the render times. Again, increasing detail should reduce their visibility.
This is exactly what I thought the problem was because you can increase detail and any nasty geometry does smooth out but it seemed like the shadows were being calculated at levels where the geometry showed the problems.
I think at present it is possible to crank the detail up enough to be not too slow and get rid of any problems at least enough so that they can be taken out with some simple post work. I went back to some scenes where this problem was bad but since I did them the rendering speeds of TG2 have improved making it possible to bump up the detail a lot more. Microvertex jittering does seem to help. Not sure why.
Just a note on those files I posted.
I'm not going further with this technique. As far as I'm concerned it's sorted. Perlin Strata 2 is the best one for getting more detail and interest in the strata if that's what you want but Perlin Strata 4 is the best for simple strata. The strata might often just be some colour where other components in the scene provide detail. So this file should be the most useful. Perlin Strata 3, as you will see, distorts the strata totally away from being horizontal in places. This can also provide an interesting effect.
Also, if you look at Perlin Strata 2 you will find that the scale of the smallest and largest feature sizes of the strata is controlled in the fractal's colour tab. The scale tab controls the overall size of the distortion. If you tweak with these settings you can go to any extreme desired - subtle undulations or huge twisting shapes. Perlin Strata 4 does a similar thing but without using a fractal.
Thanks very much for the files and experiments in strata efflux, interesting stuff.
By the way, I have found an awesome way to get multicoloured strata from an image file. The beauty is in the way Gimp (open source image editor) can create an incredibly complex gradient from a colour palette. It's really quick and easy to do. I will post eventually about that. Photoshop may have the same capability.
There is also a way to get multicoloured strata using a colour gradient hack I made. I'm sure I posted one of these in the forum but I will revisit that idea. The hack is very complicated and a bit slow.
This is one reason for a TG2 colour gradient :)
By the way, there is one thing about TG2's renderer which I really like and that is the way you can change settings while rendering. It is very cool when you are working on surfaces and making tweaks to compare one version with another but no need to stop the renderer. It would be cool if the rendering window could hold several renders in tabs to make this kind of comparison even easier. Maybe there could be memory issues though I guess, at least on some machines.
There is a way. The program saves images in the temp folder. There is a menu item to view these files.
Yes, I suppose that's probably the best way. You only open them when you need to see them.
Use Windows Photo Gallery. Just open the temp directory. You can use the forward and back buttons between images.
Quote from: efflux on August 04, 2009, 01:48:18 PM
By the way, there is one thing about TG2's renderer which I really like and that is the way you can change settings while rendering. It is very cool when you are working on surfaces and making tweaks to compare one version with another but no need to stop the renderer.
It is no longer safe to do that since multi-threading was introduced. You risk crashing the render. In future Terragen should prevent you from doing this.
Quote
It would be cool if the rendering window could hold several renders in tabs to make this kind of comparison even easier. Maybe there could be memory issues though I guess, at least on some machines.
We plan to give you the ability to flip through multiple renders in some future version.
Matt
OK thanks. I have changed settings without crashes but got the odd error message.
I think it would make things better is if we simply had one key command for render instead of the other ways - hitting render button in render properties or opening render window then hitting button. A lot of 3D apps simply have one key command that starts a render. You get used to hitting this all the time to test render instead of mousing buttons. After all it's the most command command you use.
Windows is pretty dire in terms of viewing images (I won't start a dissertation about the benefits of Linux here but once again it is way better at this) so probably a way of tabbing through images in TG2 would actually be better.
Hi
Thanks for the this - I'm doing a render now using this technique- it suits the slightly surreal, non realistic style of my work. Thanks - great work
Most files I post will be highly simplified to try to show what is happening. This idea may only be useful in realistic scenes if used subtly. However, the planet I just finished does have this technique but using the strata to blend two different surfaces. You may not be able to see this in the renders (especially since things are distorted around a lot) but take it out and you notice something is missing.
Speaking of color gradients i sampled many true color earth tones and made .aco files from them that can be read in Photoshop and i hope GIMP. So if anyone want's true colors to use for that needed realism here are the color swatch files i made.
Quote from: CCC on August 09, 2009, 11:05:04 PM
Speaking of color gradients i sampled many true color earth tones and made .aco files from them that can be read in Photoshop and i hope GIMP. So if anyone want's true colors to use for that needed realism here are the color swatch files i made.
Thank You !
Strata ... I just love strata ...
Just two hours left for a final render ...
I'll go for that :-)
Volker
Thanks efflux. This is the kind of thing a person can only wish for.
Quote from: CCC on August 09, 2009, 11:05:04 PM
Speaking of color gradients i sampled many true color earth tones and made .aco files from them that can be read in Photoshop and i hope GIMP. So if anyone want's true colors to use for that needed realism here are the color swatch files i made.
Many thanks, just what I was looking for :)
Richard
Okay,
my first thoughts about that strata-thingy.
In my point of view, strata is not only some sort of distorted layered displacements.
Following points should be taken into account:
1. Strata are layers of mud/stone of different heights, colours and/or hardness.
2. Unless being in an area without any earthquakes, we find tilted and/or curved strata. Enclosed stones distort the strata, too.
3. Strata can only been seen, where the topmost layer of soil is gone, so first of all we'll need an area of negative displacement.
The easiest way to achieve this would be, to use 2 or more merged Strata and Outcrops shaders (each with different tilts).
It might be funny, to use your height-driven perlin to blend those shaders.
Another approach I would go for, are perlins stretched along x- and z-axis. To give them some more interesting directions you could add some perlin driven sines to the y-position of the 'Get Position (in texture)'-Node.
I'll go for the last one ...
Volker
Hi Volker.
Using this to blend is very useful. I did that on my recent planet. It gives a very subtle stratification of textures to provide a natural change at altitude but you don't need anything fancy just a simple smooth blend which these nodes do nicely.
You may notice that the strata distorts more at higher altitude. For artistic results, this is OK. It's due to certain data flows positioning and interactions that are not so easy to explain. You have to kind of mentally backwards engineer things in TG2 to work it out.
Some things I still don't have a clear picture of. For example - get position, get position in geometry, get position in texture. For any kind of mental picture of geometry these names are completely useless. What geometry? What is texture? In Mojoworld this is all completely self explanatory. It takes about half an hour to play with and understand. Also - compute terrain and compute normal? These things all effect the positioning of things yet no clear explanations.
TG2 is a great app but if I had to give the documentation marks out of 10, I would give it 0 but this is not necessarily the fault of whoever writes the documentation. Maybe Oshyan does all that. I don't know. The trouble is you would have to have total technical understanding of what every node does and then understand how the possible geometry could be used for artistic effect. At present, nobody could actually achieve this task. A start would be clearer explanations of TG2's data flows and nodes. I can tell you now that if I hadn't used Mojoworld, I would have probably have ditched TG2 by now.
Well maybe 0 out of 10 is a bit harsh because there is basic instructions on how to get started but I'm only comparing to documentation of other apps.
For a start, there should be clear documentation on what you are actually doing when you use fractals and noise functions for colour values, displacements etc. This should be accompanied by diagrams of where and how the values are take because many people who try TG2 will not understand what is even happening here.
I can explain "get position in geometry" and how you derive displacement from it. The output from the "pos" node is a single [x, 0, z] value
but repeated for each point (or micro triangle) seen by the camera. Tre node tree below is called repeatly for each of these values.
In principle you first make some vector operation and then you make a transformation to a scalar (e.g a noise function, or a length function).
After this you make some tranformations and feed the resulting scalar into the second input of a displacement node.
What is important to note is that none of these oprerations changes the original point obtained from the original "get pos" point, and that
the length operationn always from the [0, 0, 0] of the current coordinate system.
In other words the process is:
1) select one or several points (fixpoints) in the X,Z space
2) among these points select the fixpoint which is nearest the point you have from the get operation.
3) Map that fixpoint onto [0, 0, 0]
4) Convert to scalar
Conceptually the mappings that you do to the selected fixpoint, is reverse so the length you measure is mapped back (measured relative) to the
fixpoint.
By mapping I means a transformation of the the coordinate system:
1) Scaling. (multiply a vector by a constant)
2) Moving the origin (subtract two vectors)
3) Rotating the vector about y.
Have fun
In other words, the get position in geometry is of no real consequence if you are working with manipulating entire noise functions or fractals.
@mogn - I'm sure that your explanation is technically correct, but what I think efflux is looking for, and what I'm sure I and the less mathematically inclined users would like, is a simple, clear illustration. Basically, actual images of what each node can be used to do would seem the best way - accompanied by a technical description such as the one you just gave.
I think the get position in geometry is useful if you were building a precise geometric shape rather than working with noise or fractals.
Quote from: Volker Harun on August 11, 2009, 03:59:21 PM
Okay,
my first thoughts about that strata-thingy.
In my point of view, strata is not only some sort of distorted layered displacements.
Following points should be taken into account:
1. Strata are layers of mud/stone of different heights, colours and/or hardness.
2. Unless being in an area without any earthquakes, we find tilted and/or curved strata. Enclosed stones distort the strata, too.
3. Strata can only been seen, where the topmost layer of soil is gone, so first of all we'll need an area of negative displacement.
The easiest way to achieve this would be, to use 2 or more merged Strata and Outcrops shaders (each with different tilts).
It might be funny, to use your height-driven perlin to blend those shaders.
Another approach I would go for, are perlins stretched along x- and z-axis. To give them some more interesting directions you could add some perlin driven sines to the y-position of the 'Get Position (in texture)'-Node.
I'll go for the last one ...
Volker
by the way Volker here's a real strata taken when I was back from my holiday...
...
...
@Aymenk: This looks very much like the Sierra Nevada in Spain. I am no geologist, though. The vertical cracks could be due to weathered erosion.
Anyhow very interesting and inspiring photographies.
At the moment I got stuck into some functions again ... Somehow I get always drawn to do some fancy stuff.
In the Mesa's Thread of Tangled Universe is some good start for strata, I think.
Then we have efflux's Thread about Bias/Gain-Blending terrains (shaders).
Looking at the function shaders the modulo-node could be used for one set of shaders, which add height to the strata.
Another set of shaders could be based on efflux's work at the beginning of this thread.
A closer look at the photographies ... the strata is building terraces, so obviously any set of shaders for a strata should shift the existing terrain without adding much detail.
,-) Volker
You can hook a colour gradient into the strata. I'll post a file as soon as I get time. One has my hacked colour gradient and there is another colour gradient by mogn which I haven't tested much. I've seen two by Mogn. You want the fancy one.
A lot of angled strata tends to form from faults from ancient and more recent tectonic movement. You can have hundreds of faults in a hundred square mile area alone. The movement creates pressure in the rock layers that bend, twist and shift the layers about and that is where you see the warping and odd angles.
Here is a uplift strata i took a photo of while out in the lower mohave desert (In a moving car). This is very close to San Andreas.
Quote from: CCC on August 09, 2009, 11:05:04 PM
Speaking of color gradients i sampled many true color earth tones and made .aco files from them that can be read in Photoshop and i hope GIMP. So if anyone want's true colors to use for that needed realism here are the color swatch files i made.
Thanks for the color swatches. At the moment I am working on a 15 color Bezier gradient using the first 15 colors from the "South West" swatch.
Quote from: efflux on August 15, 2009, 11:23:43 AM
You can hook a colour gradient into the strata. I'll post a file as soon as I get time. One has my hacked colour gradient and there is another colour gradient by mogn which I haven't tested much. I've seen two by Mogn. You want the fancy one.
By the way, I think that your color hack is some implentation of a Bezier curve.
Quote from: mogn on August 15, 2009, 11:59:09 PM
Thanks for the color swatches. At the moment I am working on a 15 color Bezier gradient using the first 15 colors from the "South West" swatch.
No problem. Looking forward to see what you come up with. ;D
I'm not sure that I can get those swatches into Gimp but I'm going to go through creating a strata from bitmap file soon. It's a very fast way to get complex gradient.
Mogn. I don't understand the maths fully but your gradient works. However I just did a test and found that for example the red doesn't come through fully.
I just botched mine together thinking about how colours need to be blended so I used all colours for the graph. The botch is the part where I have to use the other colour to blend with. This is OK. That node could potentially be utilized in interesting ways. This file has a multiple x 2 before the gradient because I think the perlin doesn't output fully up to value 1. It seems to be around 0.5. The ideal would be to be able to control the colour placement within the gradient.
Here is an incredibly fast way to create gradients using Gimp. The screen shots are self explanatory. Create a gradient on your document and make it one pixel wide. Save this and bring it into TG2's image map shader.
Used for blend.
You can also use the incredible tool stratagen2: http://sg2.jens-bringewatt.de/
BTW, I just saw cyphyr's redirect-hack on the strata-shader ... this is exactly what I was looking for :-)
Thanks efflux. I didn't know Gimp could do this.
Thanks you guys for making strata an interesting adventure. This is something you both do quite well and together even better (of course!).
I never knew there was such a thing as stratagen.
I'd like to echo Calico and thank you for your contributions. I really struggle with the little blue thingys but your posts not only inspire ideas but have led me to my best work.
Mick
I used stratagen-maps in this render: http://www.renderosity.com/mod/gallery/media/folder_154/display_1534725.jpg
Nice, great POV and texture.
efflux,
Very nice work and thanks for sharing, you are a very good with nodes.
Glen
Quote from: CCC on August 16, 2009, 12:15:15 AM
Quote from: mogn on August 15, 2009, 11:59:09 PM
Thanks for the color swatches. At the moment I am working on a 15 color Bezier gradient using the first 15 colors from the "South West" swatch.
No problem. Looking forward to see what you come up with. ;D
This is what I ended up with: (I succeded in saving the gradient colours, so I have started a new round)
I don't consider myself to be very good with nodes but I get ideas about what I want the network to do and I try to get it to do that. I'm certainly not good at any maths.
Volker,
I always thought that was a great render. Now I know how you got the strata.
Mogn,
I don't know how difficult this would be but if you could have the ability to move the colours placement points within the gradient then that would be very cool.
I may be disappearing for a while. I'm moving house. The only reason I had time for TG2 the last few weeks is that the move got delayed but after I have moved I will have lots of time for TG2 :) If I decide to use this time for TG2 but I always come back to this app.
Quote from: efflux on August 17, 2009, 08:37:02 AM
I don't consider myself to be very good with nodes but I get ideas about what I want the network to do and I try to get it to do that. I'm certainly not good at any maths.
Volker,
I always thought that was a great render. Now I know how you got the strata.
Mogn,
I don't know how difficult this would be but if you could have the ability to move the colours placement points within the gradient then that would be very cool.
I may be disappearing for a while. I'm moving house. The only reason I had time for TG2 the last few weeks is that the move got delayed but after I have moved I will have lots of time for TG2 :) If I decide to use this time for TG2 but I always come back to this app.
Well I have been thinking about unequal points in the gradient. From a mathecical wievpoint I did'nt find a solution.
But recent new insight in the workings of TG2 it might be to find a useble approximation.
Happy to have restored my 15 points South West gradiient, but I have to do more testing.
For adventures people a 15 points gradient might be build in the following way:
1) Line up the 15 colors in a row.
2) Connect 14 color mix nodes between each of the 15 colors.
3) Connect 13 color mix nodes beteen the about 14 mix nodes
4) E.t.c until you end with one node
5) Connect the 0..1 control variable to each of the controller input of the 105 mix nodes.
Simple as that :D
105 mix nodes? It would take hours just to calculate a single pixel! LOL
I haven't done and strata color layers in a while. When I did, I used surface layers with altitude constraints. This is what I came up with.
http://farm4.static.flickr.com/3153/2871232761_12b872e3f4_o.jpg
That is insane. We really need a Photoshop like gradient shader. It would be easy to implement.
Quote from: CCC on August 17, 2009, 08:55:54 PM
That is insane. We really need a Photoshop like gradient shader. It would be easy to implement.
Thats why I have solved in another way:
1) multiply the 15 colors by the constants of x in (1+x)^14 i.e 1, 14, 91, ..., 3432, 3003, ... 14, 1
i.e multiply color1 by one color 2 by 14 e.t.c
This should be fast since it is all constants.
2 If s is the controlling variable (0..1) and c is the complement, generate all 15 powers of s and c where the sum of powers is 14.
This can be done in the following way
generate s^0 = 1
generate s^1 = s
multiply to get s^2
multiply s^1 and s^2 to get s^3
build vector vs2.1.0 from s^2 s^1 s^0
multiply this vector with s^3 to get vs5.4.3
continue this until you have vector vs14.13.12 (In total 5 vectors)
In the same way build vector vc0.1.2 vc 3.4.5 e.t.c (In total 5 vectors)
multiply vector vs2.1.0 and vc12.13.14 etc
extract the 15 components from these 5 resulting vectors (X to scalar, Y to scalar, Z to scalar)
multiply the 15 weigted colors from step 1 by these 15 variables.
3)
Add all the 15 results from step 2.
Thats all
Are you sure you're not doing income tax forms? ;D
Quote from: mogn on August 18, 2009, 12:09:49 AM
Quote from: CCC on August 17, 2009, 08:55:54 PM
That is insane. We really need a Photoshop like gradient shader. It would be easy to implement.
Thats why I have solved in another way:
1) multiply the 15 colors by the constants of x in (1+x)^14 i.e 1, 14, 91, ..., 3432, 3003, ... 14, 1
i.e multiply color1 by one color 2 by 14 e.t.c
This should be fast since it is all constants.
2 If s is the controlling variable (0..1) and c is the complement, generate all 15 powers of s and c where the sum of powers is 14.
This can be done in the following way
generate s^0 = 1
generate s^1 = s
multiply to get s^2
multiply s^1 and s^2 to get s^3
build vector vs2.1.0 from s^2 s^1 s^0
multiply this vector with s^3 to get vs5.4.3
continue this until you have vector vs14.13.12 (In total 5 vectors)
In the same way build vector vc0.1.2 vc 3.4.5 e.t.c (In total 5 vectors)
multiply vector vs2.1.0 and vc12.13.14 etc
extract the 15 components from these 5 resulting vectors (X to scalar, Y to scalar, Z to scalar)
multiply the 15 weigted colors from step 1 by these 15 variables.
3)
Add all the 15 results from step 2.
Thats all
EEErrr.... yeah, just doing that now. How many grams of flour do I mix with the sugar? ;D
Quote from: njeneb on August 18, 2009, 08:07:34 AM
Are you sure you're not doing income tax forms? ;D
Certainly not, in Denmark with the world record in input taxes 8)
Since the only artistic gene I have is programming, I attack difficult problems.
Attached Efflux perlin stata 11 with his gradient hack (5 colors + 1 color tone modify) replaced by mine 15 color gradient.
The original Efflux tgd redered in 5 minutes and 12 seconds on my cpu (3 threads active)
Also attached is is the 15 color "South West" gradient.
So now to the mode diffcult, make a soft gradient with specified non equal input values.
Complicated node networks like this, would be a pease of cake, if tg2 allowed one node functions. Even an old programming language as
GIER algol in the beginning of the 60's allowed 2 ways of accessing input parameters: By value and by name. In TG2 access of input parameters
are not possible >:(.
Thank you for sharing your programming creativity :)
Quote from: mogn on August 19, 2009, 11:33:11 AM
Complicated node networks like this, would be a pease of cake, if tg2 allowed one node functions. Even an old programming language as
GIER algol in the beginning of the 60's allowed 2 ways of accessing input parameters: By value and by name. In TG2 access of input parameters
are not possible >:(.
I'm not sure exactly what you mean, I may be just misunderstanding your language. You mean like a Macro node?
What I think you really need is not a better node system, you need to be able to write functions using a scripting language. We will add scripting support in future (probably via Python).
Matt
Matt, one node functions requires the the internal can access all the inputs, also the inputs thats already assigned without the need
to got to the internal each time you apply this function. Of course you have to use this as a macro, i.e. create a copy of the node (tgc) each
time the function is inserted in a node network.
?
Quote from: mogn on August 21, 2009, 12:08:08 AM
Matt, one node functions requires the the internal can access all the inputs, also the inputs thats already assigned without the need
to got to the internal each time you apply this function.
Ah yes. That's what we'd call a Macro function node.
Quote
Of course you have to use this as a macro, i.e. create a copy of the node (tgc) each
time the function is inserted in a node network.
I'd call that a clip that contains the Macro node. Semantics :)
Matt
Hi people,
I have been away so don't know what has been posted recently but I will look through the forum in time. I have moved house and had no internet connection for a while.
Also, to tell you the truth I got very frustrated with TG2 when I developed the last planet. I'm working almost exclusively on Linux now for everything except TG2. This includes Mojoworld which works perfectly on TG2. I go through phases of using different apps. Ideas from one feeds into another.
I've got lots of time but not sure which direction I'm going in. I'm finding that doing digital painting and working in apps like 3D Coat is getting very fast results. As we know landscape building is anything but fast so I get frustrated with TG2 then abandon it, usually to return later.
I'm using too many apps and have to streamline this down. I've spent a week working on node networks in Mojo, probably thousands of nodes in my new Mojo planet. By the time I get back to TG2 I forget what I've done and can't even answer questions about it.
Probably I will spend some time in 3D Coat in the near future which doesn't require years of working out how to do things.
mogn,
I'll have a look at that colour gradient later. It looks good.
I'm going explain in more detail exactly how you can do things in Mojoworld. I have created a TG2 planet that uses the same processes as Mojoworld but there are tons of ways to use nodes in Mojoworld that is not yet possible in TG2 or at least not easily. Mojoworld will always be different because the data flow is different. There is no vector, scalar and colour differentiation in the data flow, at least to the user. This will always make Mojo slightly easier but still, there is a bunch of things TG2 needs or at least needs to be worked out. There are enough people here who have some understanding about nodes now to see exactly why coming from Mojoworld to TG2 is so frustrating even if you never used Mojoworld. It's impossible to even begin to promote TG2 to a Mojoworld user as being good. You'll see some things that you will want in TG2. Things that wish for threads should be full of. I'm not sure where to put this info, possibly in Terragen 2 discussion. I imagine some people may try to relate ways of doing things to TG2 so it's not really open discussion. I'll have to explain a few basic ideas first about Mojo's nodes which will not be hard but first thing I can describe is completely related to this thread. Here we have struggled with colour gradients and altitude. Piece of cake in Mojoworld. Of course I imagine colour gradient will eventually make an appearance in TG2 so I'll concentrate on altitude. I have a Mojoworld folder already with examples of Altitude driven fractals so it's a good start. I won't go any further here.