So, as we stare into the fading embers of a dying year, I had a chance to go browsing through the old Planetside website (circa 2006) and get all nostalgic like I do this time of year. I noticed / remembered a few things from when I started down this landscape generating path.
Firstly, that nearly every single promise was delivered by Planetside from all the features they wanted to include and said they would include at some point save 1 or 2.. Most notably, the ability to create waterfalls and do subsurface scattering. Not that I lament the non existence of such features. I haven't had a need to include either in my scenes as yet and if I did, I'd likely be able to find a suitable workaround. Nor do I have any illusion of the complexity that would be included in order to implement these features, considering all the others that have been implemented so far (and considerably more important).
And secondly, I noticed back then, there was a road map for where we were all heading. We all sort of knew what the future held and features the development team was working on. This is something that seems to be lacking now. Or is this just the difference between being established and being a start-up?
So, I guess my question is: What's in store for the future of Terragen? It's already great at what it does. More stability and minor updates / bug fixes? Will it move in the direction of being an all-purpose 3D program? Is PS keeping things close to the vest to remain competitive? Is so, let me know, and I'll never mention it again. But also, it might be a good time for others to kind of pitch some ideas of what they might want included in any updates or future versions.
Personally, before new features get added, I'd like to see the Wiki get completed. After that, more GI (or maybe a checkbox for "True Lighting (not recommended)" ;) as per my last post on the subject. I might think of 1 or 2 more things in the next couple of days. Anyone else?
Populate on an object.
Simplified stream-lined Mudbox & Z-brush integration for better vector playing.
RTO displacement issues
Better gizmo so I can tilt and rotate in the 3d preview window.
Quote from: TheBadger on December 30, 2013, 04:09:57 PM
Populate on an object.
Simplified stream-lined Mudbox & Z-brush integration for better vector playing.
RTO displacement issues
Better gizmo so I can tilt and rotate in the 3d preview window.
Those are all gold.
My wish list would be:
- Sub-Surface Scattering (besides ice it would be extremely useful to replicate organic surfaces, skin etc.)
- a particle engine system
- a more complex populator allowing to mix different objects at once
- an improved painter shader, allowing to brush using b/w texture maps
- some improvements on the user interface, mostly helpers and commodities
- a shader capable of masking by ambient occlusion or other cavity detection algorithm: that would allow to do even more nifty displacement and surfacing on terrains
- terrain generation based on a spline/bezier curve system
A lot more wishes to come ;D
Hi Michael,
Quote from: TheBadger on December 30, 2013, 04:09:57 PM
Better gizmo so I can tilt and rotate in the 3d preview window.
What problems do you have with the one TG has now?
Regards,
Jo
Its not really a problem Jo, just would be nice to have.
Usually once I get heavy into a scene working directly in the preview window may not be best anyway.
But despite you only hearing when I don't like something, there are a lot of times when my scene stays light enough to work directly in the 3D preview window as much as I want to.
At times like that it would be nice to be able to rotate and tilt objects and things directly with the gizmo. For example, THe current gizmo only allows XYZ. But I have only bought T3 an hour ago, so if its already better, never mind. Otherwise, despite limited use, when it would be useful, it would be very useful indeed.
Basically, anything that can be moved in any direction would benefit from an improved gizmo
The "gizmo" does now allow rotation and scaling and works for most things that *can* be rotated and scaled. This is new as of TG3 though, so perhaps you haven't noticed yet.
- Oshyan
Oh Good! I will install tonight just got my key tonight! Well then, I got what I wanted! Good for me. ;D
1. Stability and fluent working!
2. Real displacement with RTO, to be set per object.
3. Populate on objects
4. Vector manipulation (like in SSS's to form more complex simple shapes :o)
5. Maybe an interesting extra noise
6. ?
1 - As i asked on the webinar, individual x,y,z on populated objects when editing
the reason is to replace easily a populated object by a different individual object with a copy/paste for x,y,z
or from this point, create anything new.
Agree with Ulcos list and like to add:
7.The ability to read ZBrushs AUV,GUV andPUV mappings
(pretty unlikely,I know,but it's a wishlist after all)
.FBX object!!
And that new way Oshyan mentioned of bringing object sequences in, in a more efficient way. Can't recall what that was called right now.
This last 12 months has been an exciting and new feature-filled span for Terragen, thanks to PS again, and I'm really looking forward to what 2014 brings! Not to get too greedy, however:
1. Pause, save and resume render. Along with 'recover' from aborted render.
2. The new Gizmo is much appreciated, and hopefully will continue to evolve: a) ability to size gizmo (it often obscures the object) b) the ability to 'lock' a rotational axis.
3. The ability to globally disable with a single toggle all other objects when in Population Edit Mode (too much happening with mouse-overs from pop-up descriptions to over-anxious objects and other
populations).
4. When an object is imported have it be the 'selected' object in the preview. Same goes for items selected in the Network view, have them selected in the preview as well'
5. Add me to the better Mudbox/Zbrush support folks.
6. Institute a curve edit function to the populator to control the 'density' of distribution (i.e. thinner towards the boundaries, etc.). Mixed object populations would be really welcome.
Quote from: jo on December 30, 2013, 06:32:57 PMHi Michael,
Quote from: TheBadger on December 30, 2013, 04:09:57 PMBetter gizmo so I can tilt and rotate in the 3d preview window.
What problems do you have with the one TG has now?
The gizmo controls only work correctly at the North Pole. At the equator some controls still work like you were at the North Pole. I sometimes find that I have two ways to rotate on a certain axis and no way to rotate on another axis (as in gimbal lock). All Rotation Controls should work relative to the current orientation but they do not. For example, if you are at the equator, you must rotate your view 90° so that the planet's horizon will be horizontal in your preview. So I will try to Roll left or right and the view will Pitch or Yaw instead (but often some catty-corner combination of all three and difficult to understand what is happening). It is very frustating for doing camera path animations that travel down to the planet's surface at arbitrary places and you wish to make the belly of your craft parallel to the surface of the planet as aircraft do when they are flying within the atmosphere.
Added to this I would like to see "Shadow Popping" eliminated by taking into account geometry that may be out of frame but its shadows are in frame.
I would also like to see "Wave Scale" or some other amplitude control to be brought out as an input to the "Water Shader" so that you can damp wave action where the water is shallow or any other way you want to do it. Right now it is just a constant that is hidden inside the node.
Although I have not used it yet, I want to praise the PS team for coming up with the Vortex Shader. I feel this may fulfill the request I made a while back when I wanted to create rotational weather systems. If you look at the real Earth from space, these things are all over the place.
Ditto Dune's list
and
FBX object
What was the image in the OP rendered with?
Quote from: TheBadger on December 31, 2013, 02:57:40 PM
What was the image in the OP rendered with?
It's a SSS test from the Terragen 2 Technology Preview or what used to be called Terragen TGD, for those of you who weren't around in the old days. It was never implemented, unstable or unusable or something like that.
The image says it works. Give it to me PS!
Hello all, just joined here and a new user to Terragen.
As a new user to Terragen, and terrain modeling in general, I feel a little left out. While I'm sure each of the above comments are valid, I think one advantage other software packages have is documentation, making the learning curve astronomically faster and therefore increasing adoption.
My thought is, if you can provide the tools to make new users feel comfortable and welcome, you'll convert them to long-term customers overnight. To do so, please consider addressing these ideas:
1. Documentation/Tutorial Videos - Community sourced or other [Grasshopper3D is a good example of official and user generated all mixed together http://www.grasshopper3d.com/page/tutorials-1]
2. User interface 'Cheat-Sheet'
^^
Tutorials. Everything you need to get started.
http://www.cgscenery.com/
http://geekatplay.com/dt3.php
http://geekatplay.com/et31.php
One thing that I'd really like would be a feature that allows the selection of and re-rendering of areas of an image where you had a bucket failure and you get blacked out areas of the image, whilst leaving the rest already rendered image intact.
Regards to you.
Cyber-Angel
Quote from: Upon Infinity on December 30, 2013, 03:56:30 PM.. Most notably, the ability to create waterfalls and do subsurface scattering.
So the subsurface scattering you are referring to is for terrain, not water? (which I believe TG has)
Fully pluggable procedural erosion node or at best, a pluggable alpine fractal. Second, more fractal flavours. And the big dream here... procedural plants.
Quote from: ChrisC on December 31, 2013, 07:11:25 PM
Fully pluggable procedural erosion node or at best, a pluggable alpine fractal. Second, more fractal flavours. And the big dream here... procedural plants.
Ditto on the erosion and procedural plants.
Quote from: PabloMack on December 31, 2013, 05:33:18 PM
Quote from: Upon Infinity on December 30, 2013, 03:56:30 PM.. Most notably, the ability to create waterfalls and do subsurface scattering.
So the subsurface scattering you are referring to is for terrain, not water? (which I believe TG has)
Yes, I believe that was the case.
Documentation. With examples.
Seriously....
Quote from: masonspappy on January 01, 2014, 08:03:15 AM
Documentation. With examples.
Seriously....
For what? Sub surface scattering? Well, the example is at the start of this thread. I think, though, that this post sums it all up rather nicely: http://www.planetside.co.uk/forums/index.php/topic,14211.msg139649.html#msg139649
Which I just discovered, by the way, so I'm not a complete douche for bringing it up again.
number one would be OpenExr 2.0 with Deep output - i know Matt has mentioned this might be on the horizon
Wishlist:
- Stability
- More/Finer/Better animation curve manipulators
- A special manipulator/slider just for the suns visual appearance
For me, the visual sun effect in the atmosphere in camera or close by is just overkill in many circumstances in relationship to most given or needed atmosphere settings.
Great would be a slider, which could change the suns visual appearance/glow amount, without influencing the suns given strength to atmosphere thingies and surfaces.
Such a slider could also be a quick compensation to sometimes needed creepy sun/atmo readjustments generally or for disappearing suns in very high camera positions e.g.
where the atmosphere stops to turbo-multiply given suns base settings/visual appearances - and could be a great killer of annoying but sometimes needed fake suns I guess..
Alex
I thought of one more; rotate by function instead of parameter! Very handy. So input can be rotated (a.o.) by a function input, such as a warped line or height, or whatever.
I would call the "roadmap" of 2006 more of a "wish list", and certainly somewhat optimistic at the time, but we did manage to accomplish much of it which is great. That being said, we went through enough challenges and delays trying to deliver on our public goals (due to any number of very normal, common issues that arise in software development) that it became clear we needed be a bit less open and optimistic about things. People just get frustrated by it, and understandably so. Our approach at this point is to promise only what we know we can deliver in a relatively short time-frame, hence the Terragen 3 announcement more or less out of the blue just a couple months before final release. We are likely to continue that approach, with perhaps the occasional teaser or early look at a feature in development. A fully laid out development roadmap is not likely to be something we will publish in the future. If you look around the commercial software publishing world you'll actually find fairly few public roadmaps or other majorly forward-looking feature discussions from the developers; open source is naturally quite different, though even there you seldom see published lists of features planned for implementation.
Of course we do have an internal list of features and functionality we want to add. In fact we have a pretty detailed plan out to Terragen 4 and beyond at this point. And that's important to know, too - even though there is no publicly available plan, we're certainly keeping track of requests, feature ideas, improvements, etc. Equally important then is the reality that we have our dev plans pretty well solidified, with dev time estimates to get us where we want to be for future releases within the release windows we want to hit. This means that there's less room for random feature suggestions than would be if we were kind of taking things as they come, throwing features at the wall and seeing what sticks, but a more deliberate product/feature strategy has so far been a notable improvement for us and for users, and we want to continue with that approach. We still certainly welcome feature suggestions and implementation feedback, but there are few really new ideas at this point, almost anything one can think of has been discussed before in various threads sometimes going back years. Sometimes a feature doesn't get implemented because we decide it's not valuable enough to the product, sometimes it's just a matter of implementation time or development priority, i.e. we'll eventually get to it. Everything that has been mentioned in this thread has been discussed at one time or another, some are intended for future implementation, others we may reconsider when the time is right.
You mention competitive concerns as well, and yes this is another factor. We've seen competing products implement very similar - if not identical - features in remarkable succession to one of our releases with that feature (good examples would be full planet model and cloud altitude/depth modulation functions that allows "cloud follows terrain" easily). That is inevitable, of course. But it's not unreasonable to expect that if we had a clear roadmap laid out, some of those feature implementations might come even sooner, i.e. competitors could work to leapfrog us in features (especially as most of our competitors have larger teams than we do). Our edge remains in the quality and stability of features that we implement, but if we can pull out a few surprises, that helps us too.
We certainly hope you'll all be excited about where we take Terragen next. It's really our job to make sure that you are excited about it because that's how we make our living. If we fail to excite a majority of our user base and the wider market, it threatens our very livelihood! So for us the stakes couldn't possibly be higher, and we take the process of analyzing and predicting the market and its future needs very seriously. Part of that is looking at your feature suggestions and ideas, both explicit and implied, as well as deriving good feature ideas from problems or workflow needs we observe. We may make mistakes here and there in the process of prioritizing and implementing, but I think our biggest challenge continues to be development and overall staff "manpower", not lack of ideas or ambition. If we had a larger team, I have no doubt we'd be blowing your minds on a regular basis. As it is, we have to settle for hopefully blowing your mind once every year or two. ;)
To more specifically address some of your questions (keeping mind that I can't lay out our larger, longer-term plans): Certainly more stability and minor updates are coming. As well as not-so-minor, I'd like to think. We have a 3.1 release planned for early in 2014 which should have one or two notable new (but not Earth-shattering) features in it, along with many bug fixes, etc. We are likely to release one or more other "point release" updates through 2014 as well. These will be free for all users of Terragen 3, as has been our previous policy.
We are absolutely not moving in the direction of a general-purpose 3D program. While other more general-purpose applications do seem to be adding some competitive features, and we watch industry developments in that area very closely, we continue to feel that by focusing in the area of modeling and rendering natural phenomena, we can remain a relevant and effective part of many artist's tool set. We are continuously evaluating various options for diversifying and strengthening our position, but we will almost certainly always remain pretty tightly focused on this area.
We do have some plans for completing the Wiki documentation faster and better, along with other potential documentation-related improvements. We haven't lost sight of the importance of it, if anything it's become even more clear over the past few months. But we're also working on partnering with other content producers and supporting the development of learning resources like Geekatplay's recent releases.
Regarding GI, Matt will probably kill me for saying so, but we *have* experimented with "brute force" GI. It's quite slow, as you would expect. So it's really not likely to show up as a feature any time soon. Instead we're likely to continue innovating for higher-performance solutions like the improved GISD in TG3. Brute force is useful mostly as a reference, but it is of course the most simplistic and generally slow way to achieve the end result; more clever and optimized solutions can achieve similar quality levels in far less time and so are a better use of dev time.
In answer to Badger's comments:
We do plan to add Populate on Object some time in 2014.
Mudbox/Zbrush integration, not entirely sure how to handle this to be honest. It appears possible as-is (as the workflow threads have shown), so it may be more of a documentation/verified workflow issue, which frankly I can't help with as I(we?) don't have either program. Autodesk isn't exactly highly responsive, but we may have some luck talking directly with Poxologic to see if they have any input on an ideal workflow.
RTO displacement is *not* likely to be implemented any time soon, unfortunately. What we will do (again, some time in 2014) is add an option to affect RTO per-object/population.
Alessandro:
Don't hold your breath on a particle system. It would be nice but is far too ambitious an undertaking at this point, especially considering how good many existing particle simulation systems there are. Our general approach is more to improve interoperability with other applications so you can get the best of multiple tools working closely together. There are whole software companies focusing on particle simulation tools so if we can help users integrate them in some way with Terragen that is likely the most effective use of our time (e.g. geometry export for particle simulation interaction, environment maps for rendering, etc.).
An improved populator with some of the features you likely have in mind is planned for 2014.
Painted shader improvements are certainly something we're thinking about.
An AO/Dirt Map shader would be nice. I'm not sure of the feasibility, but it's something I've mentioned to Matt before...
Spline terrain generation is also a somewhat "big" feature, one we're definitely interested in, but not likely to come real soon practically speaking.
For everyone else: lots of misc. feature requests here and there, we'll take note, but may not be able to respond specifically to each one.
I will say though, that the requests for "stability" are a bit surprising to me. We do aim for very stable releases and in general that seems to be something we've done well with over the years, in fact we'v had a lot of feedback, particularly from new users, that Terragen is comparatively stable. If you have specific circumstances where there are stability issues that are *not* simply related to basic system resource limitations, then we'd love to hear about them. We are aware of a few such issues recently, for example the "abort while populating" crash reported in another thread which we're looking into, and we fixed a few stability issues in the 3.0.10 release after the TG3 launch, but if you do have other stability-related feedback and experiences, please let us know with more details and specifics.
- Oshyan
Thank you, Oshyan, for that awesomely detailed response. If nothing else, Planetside has the best support and response in the industry.
Quote from: Oshyan on January 03, 2014, 04:20:37 AM
If you look around the commercial software publishing world you'll actually find fairly few public roadmaps or other majorly forward-looking feature discussions from the developers; open source is naturally quite different, though even there you seldom see published lists of features planned for implementation.
Makes sense to me.
Quote from: Oshyan on January 03, 2014, 04:20:37 AM
In fact we have a pretty detailed plan out to Terragen 4 and beyond at this point. And that's important to know, too - even though there is no publicly available plan, we're certainly keeping track of requests, feature ideas, improvements, etc.
This is great to know! Even if we don't get the specifics, it's good to hear about even vague developments going on in the background. Sometimes, when you haven't heard anything for a while, strange ideas start to go through your head; "Is this the final version?", "Is the software going to be abandoned?" Although it could just be my general lack of sleep... ;D
Quote from: Oshyan on January 03, 2014, 04:20:37 AM
We are absolutely not moving in the direction of a general-purpose 3D program. While other more general-purpose applications do seem to be adding some competitive features, and we watch industry developments in that area very closely, we continue to feel that by focusing in the area of modeling and rendering natural phenomena, we can remain a relevant and effective part of many artist's tool set. We are continuously evaluating various options for diversifying and strengthening our position, but we will almost certainly always remain pretty tightly focused on this area.
Understandable and probably desirable, as there are plenty of general-purpose modellers and renderers out there. One question, though, will there ever be an option to animate (rig) imported objects? For example, import a fish, and then have the fish not only move, but also swish its tail, or something similar? Or does Terragen already have a feature / work-around for this? I'm not too knowledgeable on the animation version.
Quote from: Oshyan on January 03, 2014, 04:20:37 AM
We do have some plans for completing the Wiki documentation faster and better, along with other potential documentation-related improvements. We haven't lost sight of the importance of it, if anything it's become even more clear over the past few months. But we're also working on partnering with other content producers and supporting the development of learning resources like Geekatplay's recent releases.
I wonder if this couldn't be done with some of the more active forum members. Maybe have them submit a write-up for a particular node, then you could just scan it for accuracy, edit as necessary, and then it's done. Wikipedia is all user-submitted, I'm certain we could pull it off here. Maybe offer credit or a link to someone's site if we need to get motivation going.
Quote from: Oshyan on January 03, 2014, 04:20:37 AM
Regarding GI, Matt will probably kill me for saying so, but we *have* experimented with "brute force" GI. It's quite slow, as you would expect. So it's really not likely to show up as a feature any time soon. Instead we're likely to continue innovating for higher-performance solutions like the improved GISD in TG3. Brute force is useful mostly as a reference, but it is of course the most simplistic and generally slow way to achieve the end result; more clever and optimized solutions can achieve similar quality levels in far less time and so are a better use of dev time.
Nobody should really hold that against you guys. Anyone who's used a pure ray-tracer knows that those kinds of compromises are necessary to achieve reasonable render speeds, otherwise they become exponentially longer with every added detail. Still, a checkbox would have been nice, but I think I have the GI working the way I need it now, so it's less of a concern.
Regarding animation, we currently support sequences of OBJ objects, which can be used for animated objects, though at the cost of very large object file sets. This was used for an animation last year: http://www.youtube.com/watch?v=3_T6zhiI2aM
Object sequences are not necessarily used that much because they're kind of inefficient. We do hope to add support for importing other animated formats in the future however, including FBX, Alembic, and possibly others. So in answer to your question, I don't think it's likely we'll have built-in character animation or non-procedural model deformation/animation tools any time soon (we do have the procedural mesh deformer input already), our approach will instead be to maximize the ability to load and render high quality animations made in other tools more dedicated to that task.
The Wiki is already openly editable and we certainly encourage knowledgeable community members to contribute. We'll gladly review and improve anything that others add. But it's a lot to ask of people, too. So far there have not been tremendous contributions to the docs outside of Planetside staff.
- Oshyan
QuoteIn answer to Badger's comments:
We do plan to add Populate on Object some time in 2014.
Thats great! Just think of all the possibilities!
QuoteMudbox/Zbrush integration, not entirely sure how to handle this to be honest. It appears possible as-is (as the workflow threads have shown), so it may be more of a documentation/verified workflow issue, which frankly I can't help with as I(we?) don't have either program. Autodesk isn't exactly highly responsive, but we may have some luck talking directly with Poxologic to see if they have any input on an ideal workflow.
Mostly I just want to see it promoted as a vehicle for image creation with Terragen. I want to see more images that use it, and more talk about how and why people did what they did with it. A Terragen-mud/z-world M/geocontrol2 workflow is pretty amazing! But one person can only make a few images in a year, usually ( it feels).
But 100 people could make a book worth of images!
And by the way guys, its not so hard for artists to collaborate on an art book. I can think of more than a few people around here who should get together and publish a collection. There are a ton of ways to do it, and to sell it.
QuoteRTO displacement is *not* likely to be implemented any time soon, unfortunately. What we will do (again, some time in 2014) is add an option to affect RTO per-object/population.
I think most of *my* "problems" would be solved with the per-object abilities. displacement with RTO on is really more of an ideal for me.
Mostly I ask and talk about what I think is an ideal way to use the software, rather than that the software does not work. Im very interested in general, about the refining process of things.
Thanks for the feed back Oshyan. U-I and others are right, Staff involvement here is mostly unmatched from what I have experienced on the net.
And don't get people started on autodesk! saying "
Autodesk isn't exactly highly responsive" Is a bit like saying its warm in hell. ;D... Yeah, but its a dry heat ;)
Hi,
Quote from: Oshyan on January 03, 2014, 04:30:46 PM
The Wiki is already openly editable and we certainly encourage knowledgeable community members to contribute. We'll gladly review and improve anything that others add. But it's a lot to ask of people, too. So far there have not been tremendous contributions to the docs outside of Planetside staff.
Actually, someone recently contributed a bunch of GIFs showing the effects of various settings for some nodes which is greatly appreciated. They added them and I've rearranged them to suit the docs layout a bit better. I've just figured out who it was too, I must thank them.
Regards,
Jo
direct link, please^^
Oh yes Jo, those are great to see. Badger, here are some examples, they're scattered around though (nice contributions by Russe166/Michael):
http://www.planetside.co.uk/wiki/index.php?title=Fractal_Warp_Shader
http://www.planetside.co.uk/wiki/index.php?title=Heightfield_Erode_v3
http://www.planetside.co.uk/wiki/index.php?title=Surface_Layer_-_Effects_Tab
- Oshyan
AHHHH!! Thats what Im talking about! Just seeing that saves me hours! Freaking hours! Days even! Thats half of it right freaking there!
Find this person and make love to them, damn it! Or at least give him a free license or something. And then ask him to do the same for every node and combination lol!
I'm already on it. :)
- Oshyan
Great news and being a programmer myself, I agree on the development insights that Oshyan kindly shared.
Quote from: Oshyan on January 03, 2014, 04:30:46 PM
The Wiki is already openly editable and we certainly encourage knowledgeable community members to contribute. We'll gladly review and improve anything that others add. But it's a lot to ask of people, too. So far there have not been tremendous contributions to the docs outside of Planetside staff.
Every once in a while I'll see comments about volunteers creating documentation, and I can only sigh. So, If you'll allow the perspective of someone who has made a living managing teams of programmers for 20 years throughout the United States, let me say without equivocation that it sounds like a great idea, but it doesn't work in real life. Programmers love what they do, and constantly set challenges for themselves which they delight in overcoming. But they do not put the same enthusiasm into documenting their creations. That's not in-line with their creative bent. That creative streak runs rampant across these boards, and is a major factor in pushing Terragen to where it is today. Creating stuff is fun, cool, groovy, thrilling, challenging, sexy and satisfying. Typing up words to describe that process is, well, not so much fun, so it gets low priority in the scheme of things. This is why we have a position of "Documentation Specialist" in some of our projects. If Terragen is to be documented properly (as I would expect in any mature and 'public-ready' software package) it almost certainly will come about only if it is defined as a set task with clear assignments to people designated for those specific tasks. I hope these comments are not taken as criticism or misinterpreted as denigration of the product - they certainly are not - but they are an honest take on what will be required to properly complete this task.
Indeed we agree masonpappy, and we're working on approaches to accomplish that, within the limitations of our staff time. We certainly don't *expect* people to contribute a lot to the docs, but we made it possible for a couple of reasons. One big reason is that people do have their own methods of working, tips, tricks, etc. as well as tutorials that will sometimes be written, and the wiki is a better place to put those than in the forums where they'll get lost, and where formatting and interlinking tools are not as sophisticated. People can also add value to existing documentation with their own example images, files, etc. if desired. It's intended to augment, but certainly not be the basis of or sole method of creating the core documentation.
- Oshyan
Quote from: Oshyan on January 03, 2014, 08:33:03 PM
............
written, and the wiki is a better place to put those than in the forums where they'll get lost,
.............
- Oshyan
How about a big instantly visible link to the wiki on the index page then? ;)
Documentation has been discussed lots of times, and in my opinion not everything can be documented. There are so many variables and possibilities of mixing, adding, subtracting nodes, with all sorts of values possible, that even a slight change in one link or value may change the whole lot. I think a user should get to know the basics and possibilities first, and experiment a lot. REALLY A LOT! I've just found that using values of minus 20 and minus 10 in a color adjust shader does things to a gradient after a displacement shader to scalar, for instance. If I'd stayed in the plus values, I'd never have found what I needed. Think blacks, grays and whites....
I would like to be able to hide cameras in the preview. My current scene has so many cameras that I can't see what I'm doing.
Turning stuff on and off in the preview would be usefull. It can get very cluttered very quickly.
^^ Select the node in question, and hit the "D" key. Node is then hidden. Select the same node again and repeat, the node is then un hidden. A hidden node will not render.
Additionally, you may in the node main window, select render as bounding box, wireframe, or hidden. THis is not the same as the above mentioned steps. THis method is more like hiding a layer in PS.
Some things in the preview are still required to give shape, so turning off SSS (Grrr) doesn't help. Road masks for example. Cameras for distance shaders, etc.
Oh yeah! Sorry, H. I know what you mean now.
More control is much desired!
Link to the Wiki is a sticky in "User contributed tutorials" and there is also a link from the main website front page (in sub-menu). Should it be somewhere else?
- Oshyan
I strongly agree with Jon that it would be very handy to also be able to hide things like simple shapes and cameras.
And, Michael; speaking of books. I've been playing with the thought to make a(nother) book with my renders, but hesitate as it's a lot of work and won't sell that good. I did one: http://au.blurb.com/b/256221-ulco-glimmerveen-the-paintings (http://au.blurb.com/b/256221-ulco-glimmerveen-the-paintings), but sold only a couple.
I already know your book Ulco and my favourite is your Red lemurian (maybe because my wife is from Madagascar ;) )
Ah! So you're one of my few buyers... thanks!
Hi Ulco,
Dont make it about sales. Just be happy to let people have a chance to own art. Its not easy to sell books on your own. But if you team up with say 5-10-15 others And all put in a 2-3 images (full page, full color) Split the costs and only make the money back plus maybe a few, that would be pretty great.
Plus, you know a first print does not have to be massive. Just as many as needed to bring the cost down per copy to make it a fast seller.
And you have to market it on more than just the printers page, amazon, deviant, and others. Amazon would be among the best though. And anyone can sell there.
Blurb is cool. But I was imagining a finer quality printing service.
Hope some people do it at some point!
I will look at your book now Ulco, the cover is a great hook!
Thats pretty nice Ulco. Only could see 15 pages. But there were at least two images I would buy the paintings of if I had any money. Not that there were only two good ones, just buying art is personal. I would like to see the other 52 paintings.
Its on my wish list to see a terragen artists book. Only the best 2-3 renders from any of the artists. But not just pure TG only. But also Finished comped Digital art that used TG in the process. Not a tut book, a art book.
+1 for the idea of a Terragen book with 2 or 3 renders of the artists.
By the way, as a bookshop owner, i know how it is hard to produce Art books and harder to sell them.
Minimum quantity (in order to lower the producing price) is 500. And the minimum cost per unit is about 20 to 25 euros.
So you need to think such a project with a budget between 10000 and 15000 euros.
Crowfunding project maybe ?
Quote from: kaedorg on January 05, 2014, 05:02:36 AM
Crowdfunding project maybe ?
Not a bad idea.
I have no problems at all with paying 25-30 dollars for a good reference art book. I much prefer paper and ink to LCD.
Your numbers feel a bit high to me though, kaedorg.
Oshyan - I just think a new user or visitor would search for it on the first
page.
I would like to be able to right-click on keys in the curve editor, select Edit and change the Frame# and Value for the key textually.
A repeat, but seeing a few people other than me sometimes have problems keeping an object or population selected for moving, etc.......
Why can't this be done:
[attach=1]
Check the box and whatever is selected (or new selection) will stay locked until you make another selection. Probably rather than a checkbox, just "greyed out" text when the lock is on and toggles back to regular text when off.
Quote from: jaf on January 07, 2014, 12:26:43 PM
A repeat, but seeing a few people other than me sometimes have problems keeping an object or population selected for moving, etc.......
Why can't this be done:
[attach=1]
Check the box and whatever is selected (or new selection) will stay locked until you make another selection. Probably rather than a checkbox, just "greyed out" text when the lock is on and toggles back to regular text when off.
Interesting actually!
Good idea there are occaisions when this would be useful
If your amiable (In Principle) to zbrush/ mudbox integration: the most logical application after that in terms of industry exposure and a development team known of collaboration would be the Foundry/ Luxology application Modo maybe contacting Brad Peebler and working on a way to leverage what Modo can bring to the table (It even supports displacement and has a development API) would be some thing for future consideration, if it is not on the road map already.
Regards to you
Cyber-Angel
My most wanted feature is a square and a crystalline noise.
If I consider the type of stuff I make, the quality I'm after and the volume I produce then faster rendertimes are nice, of course, but not that super-important to me anymore.
I don't mind rendering hours or over a day for a full HD still.
I want photographic results and it's especially that niche Terragen tries to fill in, creating large scale photographic CG landscapes.
Which it does pretty well by the way, except for some situations. I find that most of the rendering time is consumed by vegetation and water...
Therefore I'd really really like to see a bi-directional path tracer or any kind of 'modern' raytracer instead of the current relatively quite inferior raytracer.
(Multiple) Importance Sampling in combination with path tracing / advanced ray tracing is what every commercial renderer uses and/or aims for these days. See the last "Current state of rendering" at FXGuide: http://www.fxguide.com/featured/the-state-of-rendering/
Terragen has to follow this trend, or I should perhaps better say I hope they will follow this trend at some point to keep the visual quality competitive or up to par with the output of most other renderers used in the industry. Well, that could be a possible motivation for Planetside.
For me it's the possibility to render more photographic looking vegetation and possibly allowing for more advanced shading effects, like SSS or more photographic looking water. TG's water lacks that glossy wet look, to me it looks like reflective wrinkled metal foil.
Perhaps an improved raytracer or path tracer would also allow for real(istic) refractions and volume effects in the water.
Also GI/ray detail is quite low in TG. Render a dense forest from distanec with GI 8/8/4 with plenty atmo samples and AA16 full, then open EXR in Photoshop and the shadows are pitch black = no GI + still quite noisy vegetation despite the vast number of AA samples.
Modern renderers use these much more wisely/effective and efficiently.
(a partial solution is rendering at at least quadruple size)
Anyway, that's quite a long story for a single, but not the least by far, wish of a modernised ray tracer and GI solution.
Quote from: mhaze on January 13, 2014, 06:16:33 AM
My most wanted feature is a square and a crystalline noise.
One or two more noisetypes would be useful, although you can do quite a few things already, but a more square-like noise could be handy for rocky stuff.
Crystalline noise? Sounds a bit like a voronoi-like noise? Do you have an example?
Square noise is also a voronoi noise, but then with Manhattan distance function.
There's plenty of (pseudo)code available on the net, so shouldn't be too much of a challenge technically.
It's a matter of priorities as well of course.
Surface-wise and if it were for me to say then I'd like to see something more directly controllable, almost sculptable and with volumetric surfaces allowing for arches and what not.
Like with these wishlisht topics the wishes are kind of endless and so is the variety of the wishes, so definitely not the easiest topics for Planetside to filter through!
Cheers,
Martin
Crystaline noise - a 3d noise say multiple sided coming to a point like a crystal or just voronoi with a number of sides option but sharp edged. Hope you get the idea :o
As far as I remember there was once a PDK announced.
I'm pretty sure that the ability for plugins would trigger the creation of a lot of them and by that "solve" the issue with getting wish lists into reality.
Personally I would also like to get a better support for macros which was discussed several times as well.
I'm sure that increasing the flexibility of Terragen by adding these features would lead to a hell of user created plugins, add-ons and macros.
Related to documentation I have to say that the current status is pretty good. The Wiki contains roughly everything to start with Terragen and the rest one needs to figure out by experiments. Now that the render speed is much more acceptable and crashes are fairly rare, experiments are not really boring anymore.
However, one wish I have: couldn't the data types used and the data streams be described really in detail?
What I'm looking for is a description like part of an interface spec...
Regards & all the best
Engineer
I'd like to thank Oshyan for the interesting insights and thoughts. I believe the approach to future releases is very mature and I really appreciated the way plantside is moving ahead.
I just wanted to give me 2 cents for the wishlist (I didn't find the items in my list in this thread, but please forgive me if I overlooked):
1) GPU rendering (using the processing power of the graphic card)
2) possibility to lock a camera or cloud/other element (simple but VERY useful feature for multiuser works. Password protected elements would also be great)
3) rendering cropped areas at full render resolution. This would be excellent to allow very flexible creation of sub-images to compose VERY large final images (outside TG).
4) better ortographic/spherical camera features. As far as I've seen, today is not optimal and maybe incomplete
sirio
-- Ability to minimize, close, or otherwise hide the tree-view on left side of screen so I can use the whole width of my screen for the network and preview windows.
Quote from: gregsandor on April 29, 2008, 07:16:26 PM
I agree with Reck, and would add that I want to be able to fill my screen with the 3d Preview window and the node network; I never use the hierarchy menu but the ability to use my entire workspace would be a great help.
-- Graded transparency in shaders without having to use a water-shader workaround.
Quote from: gregsandor on December 08, 2008, 01:30:02 PM
Have any of you been able to get a good glass shader for cars and planes? When I set transparency on a shader it is either on or off; I want to show the canopy of my plane but haven't found the right settings yet. I'm now using a water shader.
-- Displacement on raytraced objects.
Quote from: Oshyan on April 14, 2010, 05:53:46 PM
It's not likely that a fix for this will make it into the next update, but we certainly intend to address it in the future. ...
- Oshyan
-- Terrain model stats in TG3.
I still often open terrain models in the original Terragen just for the purpose of getting the point count, meters per pixel, altitude range and total size. It would be convenient to have these values visible in the Heightfield Shader dialogue.
--- Add the ability to lock the location of an object. In scenes with lots of models, it is too easy to accidentally move one when you mean to grab another.
-- I like being able to hide the camera model but also want to hide the frustrum lines, same for bounding boxes and axes of terrain and models. Once a scene starts really building up it gets too cluttered to see what I'm working on.
Something little, but very helpful comes into my mind as I went several times in time cost trouble because of it the last weeks..
If this was mentioned before and I've overseen it, I have to apologize and the chance I'm doing something wrong generally is also there..
I would like if there would be an automatism, which deactivates the mask function of a influenced shader, everytime a influencing function or masking shader gets deactivated or deleted.
I hope you know what I mean..
Sometimes you work with personal alpha like area masks or a just simple shape shader e.g., which may influencing previously a lot of other shaders, not just one shader.
By deactivating the masking shader, the masking function in all influenced shaders stay checked - at least for me, and ends up in not wanted results.. :/
I have to disable all masking functions in every influenced shader manually.
Also, when I copied some shaders from one project into another (which were influenced by a masking shader previously), they end in a "working" scene.
Problem is you just get the result of a destroyed scene after closing your project and when you open it again, then parse error lines and stuff will hit you and the scene isn't usable anymore.
Maybe it's just me and my sciolism, again, then I have to apologize!
Updated my post above.
Quote from: sirio on January 17, 2014, 02:15:18 PM
3) rendering cropped areas at full render resolution. This would be excellent to allow very flexible creation of sub-images to compose VERY large final images (outside TG).
There isn't an option in the GUI, but this can be done if you run Terragen with the -cropoutput command line option. From the command line documentation (in the docs folder on Windows or the Documentation folder on the Mac):
Quote
-cropoutput
Crop the output image(s) to the dimensions of the rendered region (defined by "crop region" and/or -tilex, -tiley), i.e. do not pad to the full image dimensions.
This works for automated renders from the command line and it also works for any render you do from the GUI if the program was started with that command line switch. If you create a batch file or shortcut that runs Terragen with the -cropoutput argument then all your renders will be saved like this. The Render View still displays the full width and height though.
On Windows, create new Batch file (a text file with the filename extension .bat), and edit it with the following:
.\tgd.exe -cropoutput
Put the .bat in the same folder as tgd.exe.
Matt
I use the graph editor extensively in Lightwave and I was happy to see the curve editor in TG2 when it came out. Correct me if I am wrong but it seems that in the TG curve editor you have to either select linear or TCB for the whole curve. You can't select the mode for individual keys. Also, the Lightwave graph editor allows you to loosen or tighten the effect of each key so that you can adjust whether the curve happens upon entry to the key or as it exits (or anywhere in between). I recall that, in Maya(?), this is done with some handles sticking out of the key's node. In Lightwave it is just a continuous parameter that varies from -1 to 1. It would be nice to be able to have this adjustment on a per-key basis as some curves go too far in one direction in preparation to be in-line to be moving toward the next key upon exit from the previous key. I have been using additional keys in an attempt to tame some of the wild motion that happens when using TCBs.
Hi,
Quote from: PabloMack on January 21, 2014, 10:41:47 PM
I use the graph editor extensively in Lightwave and I was happy to see the curve editor in TG2 when it came out. Correct me if I am wrong but it seems that in the TG curve editor you have to either select linear or TCB for the whole curve. You can't select the mode for individual keys. Also, the Lightwave graph editor allows you to loosen or tighten the effect of each key so that you can adjust whether the curve happens upon entry to the key or as it exits (or anywhere in between). I recall that, in Maya(?), this is done with some handles sticking out of the key's node. In Lightwave it is just a continuous parameter that varies from 0 to 1. It would be nice to be able to have this adjustment on a per-key basis as some curves go too far in one direction in preparation to be in-line to be moving toward the next key upon exit from the previous key. I have been using additional keys in an attempt to tame some of the wild motion that happens when using TCBs.
Yes, your assumptions about how things work are correct. We have improvements planned for the curve editing.
Regards,
Jo
Quote from: Matt on January 19, 2014, 07:13:46 PM
Quote from: sirio on January 17, 2014, 02:15:18 PM
3) rendering cropped areas at full render resolution. This would be excellent to allow very flexible creation of sub-images to compose VERY large final images (outside TG).
There isn't an option in the GUI, but this can be done if you run Terragen with the -cropoutput command line option. From the command line documentation (in the docs folder on Windows or the Documentation folder on the Mac):
Quote
-cropoutput
Crop the output image(s) to the dimensions of the rendered region (defined by "crop region" and/or -tilex, -tiley), i.e. do not pad to the full image dimensions.
This works for automated renders from the command line and it also works for any render you do from the GUI if the program was started with that command line switch. If you create a batch file or shortcut that runs Terragen with the -cropoutput argument then all your renders will be saved like this. The Render View still displays the full width and height though.
On Windows, create new Batch file (a text file with the filename extension .bat), and edit it with the following:
.\tgd.exe -cropoutput
Put the .bat in the same folder as tgd.exe.
Matt
Thanks Matt. If that could be made possible within UI in future releases I'm sure non-IT users (but maybe excellent artists!) would appreciate it :)
Sirio
Quote from: jo on January 21, 2014, 11:35:11 PMYes, your assumptions about how things work are correct. We have improvements planned for the curve editing.
I had to edit my previous post because the Lightwave tightening parameter varies from -1 to +1 (and not from 0 to 1).
I think that even the way the Lightwave editor works could be improved. It seems that the tightening parameter mostly seems to affect how the curve exits the key. This makes it difficult to control entry into the key when the previous key has linear selected. If the control for any key were symmetrical about the key then it would be ideal. Linear would cause the smoothing of the curve to enter the key from either side under the control of the adjacent key. Linear would only relax the requirement that a line has to be smooth while passing through the key. So in linear mode, there would be a "corner" and a sudden change in direction is allowed. Then TCB would force smoothness through the key. A tightening parameter of -1 would make all curve correction happen before the key. A value of +1 would make it all happen after the key. A value of 0 would even out the correction so that it is symmetrical about the key on both sides of it. In all cases, though, the curve would be smooth. The only places where the animation line has sudden direction changes is at linear keys.
Another mode that I use quite often in Lightwave is the "Stepped" key attribute. This makes it possible to place an object out of view and suddenly make it appear at a new place with no interpolation in between. Sometimes there is a need to change an object's animation parameter instantly. Of course this mode would only affect the animated parameter during and after the key but not before. This would be a nice feature to have in TG as well. It is generally much easier to place an object out of frame until it is needed than it is to control its visibility. You could place a tree below the ground, for example, and then suddenly put it in place. Of course, if you want it to fade in, you have more work to do. Also, it takes some thinking to understand how the curve should behave between keys with different modes. The behavior of the curve between a stepped follow by linear is different from a stepped preceded by a linear and does not exhibit symmetrical behavior, for example.
Quote from: mhaze on January 13, 2014, 06:16:33 AM
My most wanted feature is a square and a crystalline noise.
What do you mean by Square noise, something like one of these?
Hi mogn,
That screen grab of your network and results interests me a great deal.
Would you be interested in posting a clip, number one. And number 2, would you be able to make those cubic forms much more rectangular, and perhaps increase the amount of variation between the rectangles?
Hi Mogn, yes something like that but more random and organic. It would also need to be 3d so that it showed in the y direction. It would need to be smoother at the edges perhaps, like the SSS shader, with a radius or bevel option
Quote from: TheBadger on January 27, 2014, 10:16:39 PM
Hi mogn,
That screen grab of your network and results interests me a great deal.
Would you be interested in posting a clip, number one. And number 2, would you be able to make those cubic forms much more rectangular, and perhaps increase the amount of variation between the rectangles?
Well after some thoughs (not easy considering my age) I came out with this:
Well, that's pretty nice, mogn. One might split up the colors and lead them to several directions if necessary. Bit of warp perhaps. Nice to experiment with this. Thanks!
Thanks, it's very close to perfect but we still have continuous vertical and horizontal lines. No time to play at the moment so I'll have to leave further dev to others.
Thank you! Really interesting.
Quote from: mhaze on January 28, 2014, 04:28:07 AM
Hi Mogn, yes something like that but more random and organic. It would also need to be 3d so that it showed in the y direction. It would need to be smoother at the edges perhaps, like the SSS shader, with a radius or bevel option
The bevel mask is calculated from the unit size of the X and Z axes, and a bevel width (0..1).
The nodes can be found inside the Beveloutput node.
Thank you mogn, I assume I could get a more random effect by mixing noises when my render is finished I shall play
Oh man thats complex! :o
Quote from: TheBadger on February 01, 2014, 10:28:00 AM
Oh man thats complex! :o
Nah it is easy for him! This was his first toy when he was 1 years or so i heard but it could be earlier i think :o
[attachimg=1]
Sadly this is close but black ares have bevels too which means there are a lot of "Walls floating around! but it's possible to get some interesting patterns. Just not the sharp square edged flaky rock I'm trying for! Sorry mogn and thanks again for trying.
Hi Mick and Planetside,
Voronoi noise using Manhattan distance function is more squarish and perhaps what you're looking for I think.
Although other variations certainly qualify as well or are may be even better!
Since TG's texturing stuff is inspired by the book "Texturing & Modeling, A Procedural Approach" I'd like to refer to the chapter "Cellular Texturing" starting at page 135.
Especially page 138 explains how to get interesting voronoi patterns using more simple bases of the voronoi function.
Currently the voronoi function in TG uses 2 base functions (F2-F1, and derivatives of that).
However, if you also introduce F3 and F4 bases to the function stuff can get very interesting.
On page 139 there are 20 variations of voronoi shown (utilizing more base functions), some of them are very appealing and would offer great texturing and displacement possibilities!
We now have a voronoi fractal appeared which still uses the same blue node voronoi pattern (F2-F1), but then utilizes different scales and amplitudes of that pattern to create a fractal, instead.
So we have something now with the voronoi flavour in the PF, but it's not quite there, yet.
So a more complex voronoi function seems to be desired!?
Anyway, the info/hints are in the book and on the net there are even practical coding examples available.
Mick (Mhaze), this is what you're looking for I think?
Just file an official request for it and maybe they will consider it?
Generally speaking these lengthy topics aren't considered as official request topics, but rather general discussion.
They are not being ignored, but filing an official request helps Planetside sieve the countless different wishes from the list.
These are difficult topics for them to go through since it's basically about a lot of drooling people sharing their TG feature fantasies ;D lol
Perhaps if others and you also request for it some things perhaps may start moving, finally, since this isn't the first time it is being discussed and requested ;)
So with some combined positive effort we may be able to give it a bump up on the priority list :)
Cheers,
Martin
Thanks! That sounds interesting I have the book so I'll have to have a read. I will file a formal request after I have studied the book.
Speaking of noises, I found this site. Just think of what could be possible for terrains.
http://www.neilblevins.com/cg_education/procedural_noise/procedural_noise.html
Bercon Noise and Chebuchev look interesting along with Manhatten.
Quote from: mhaze on February 03, 2014, 05:09:36 AM
Bercon Noise and Chebuchev look interesting along with Manhatten.
The section "Blocks Oddly Shaped Variations Organic" in Neil Blevins page look very interesting as well.
It's Bercon combined with Chebuchev and distorted.
It looks very neat :)
Anyway, we can go through all of these of course :)
Just doing some tests with image maps from the above site. The chebychev are working well but these are from image forge which I have some where. However using image maps has problems in some situations so a proper 3d noise node would be a lot better! just realised I'm using "Blocks Oddly Shaped Variations Organic" from Neil Blevins page and yes they are interesting - will post later
Reading through these posts revealed some interesting 'wish' items.
I think TG is an excellent program for what it is supposed to do and I think non terrain items should not be an area of concern.
I, and I hope I'm not alone, use TG as the "stage" for objects developed in programs that are specifically designed for object modelling / cad. Bearing this in mind I have the following wish list.
1-More import options and either the repair or elimination of the LWO import. ( Inclusion of an external product or joint arrangement like TG and Xfrog)
2-Return of the sculpting feature of the Classic Version.
3-A command that allows the user, once he/she has found the exact location they want, to "re-Origin" the world to the center of the 'found' location. This could be the addition of a 'user coordinate system' in addition the world coordinate system.
4-(And I know this would be difficult). Refine the wiki so that material relevant to later releases is highlighted, or in a different font, or something. Also provide an easy way for offline use of the wiki information.
Ed
Hi Ed,
1: We'll likely add FBX model import in the future (we already have import of camera, lighting, animation data in FBX, of course). What other formats would you want us to support? Keep in mind we need to focus on the most widely supported formats in other programs too, to maximize return on our efforts.
2: The "Sculpting" feature in Terragen Classic can be almost exactly duplicated with the Painted Shader, and it (the Painted Shader) can do a whole lot more besides - it's much more versatile. To get the basic "Terragen Classic" style of sculpting quickly, just add a Displacement Shader to your Terrain network (on the Terrain layout, click Add Terrain -> Displacement Shader and select Displacement Shader). Then open the Displacement Shader's settings and where it says "Function", click the green + button on the right, select Create New Shader -> Colour Shader, then select Painted Shader. The Displacement Shader takes brightness values as input and interprets them as levels of height (displacement), where white is the maximum (equal to the Displacement Multiplier, which will effectively be height measured in meters), and black is 0 displacement. So what you're doing is feeding the Painted Shader output into it to define displacement area and relative height. You'll want to set the Displacement Multiplier to say 100 for now. Finally, go to the 3D preview, click the icon that looks like a paint brush at the top, click Start Painting and select Painted Shader 01 that you just created. Then you can start painting displacement. With the default camera view and Painted Shader brush size, it will give you too much displacement in the foreground, but you can try painting on the mountain in the background to see the effect easily. Ideally you'll want to move the camera up so you have a good aerial view to paint with, of course. You can just select the Top view in the 3D preview camera controls if you want to really duplicate the more limited TG Classic approach.
The control you have over the Painted Shader is more than you had in Classic, and you can also paint almost any kind of displacement this way by using the Painted Shader as a mask instead (i.e. paint the Alpine Shader only where you want it to go). I know all that sounds complicated, but it's actually pretty simple, and once you do it a couple of times it'll be second-nature.
3: You can change the "Lat/Long at Apex" in the Planet node's settings. It sounds like that would be similar to what you want.
4: Most of the information in the Wiki is relevant to both Terragen 2 and 3. We're updating all the info progressively over time, so it's an understandable concern. If you find something that looks particularly out of date let us know. We do know that the "Getting Started" guides are still Terragen 2 specific.
- Oshyan
Oshyan-
Thanks for the detailed reply.
1-I was thinking of 3DS for one.
2-I'll look at this in more detail.
3- I was referring to the Topic: Resetting the origin - which I made earlier. I will try your suggestion.
Ed
Here is a wish of mine. I do a lot of flyover stuff and it would be great if the vegetation population zone could follow the current (Master) render camera. If there was a check box (perhaps labelled "Center at Render Camera") as an alternative to the hard-coded "Area Center" in the Populator Node, then the vegetation could follow the camera whereever it goes. This would be where the normal from the planet's sphere intersects the render camera's current position. The terrain would, theoretically, never run out of vegetation and the vegetation zone would reach as far as you have sized the area. Of course the vegetation would have to be repopulated periodically if not on every frame to do this. There is already a "repopulate on every frame" check box. Critical to this is that all instances would have to end up in the same places, sizes and orientations across repopulations. It would also be nice to not populate objects that are not visible because they are below the horizon. This could reduce render times and save memory space. My 16GB of DDR3 is getting too full from populations alone. Wouldn't want to eliminate instances that you could see in reflection. I can't see any realistic reason why the camera would ever see the reflection of an instance that is below the horizon. Perhaps in science fiction there might be some sort of giant mirror in the sky.
3DS is a very old and outdated format, less widely supported than OBJ. I haven't asked Matt or Jo about it, but I suspect it's unlikely to be added as we still need to add Alembic, which is a far more modern and generally useful format. I understand you may have some programs that use or like 3DS, or have some resources available in that format, but it's really a pretty legacy format at this point and I think you're best off finding ways to convert it into more standard formats rather than hoping applications add support for it. The trend is likely to be the reverse, away from 3DS rather than towards it.
http://usa.autodesk.com/adsk/servlet/pc/item?siteID=123112&id=20481519
- Oshyan
Speaking of formats wish list items, I'd love to see some sort of alembic support, along with the ability to offset those geo cache files on import to add variation to the alembic sequences. Would be great for example to generate 1000 frames of ambient wind blowing through a single tree done in say Speedtree, or whatever your deformation program of choice is and then instance that tree how ever many times in TG but tell the importer that you want to grab random sections of the geo cache file so in addition to random scaling, rotation, and placement in your Terragen scene you also get variation in the animations of the trees themselves. It would be very fast and easy to populate entire forests of alembic trees and bushes with subtle, realistic wind motions on them.
Quote from: gregtee on February 19, 2014, 07:53:24 PM... to populate entire forests of alembic trees and bushes with subtle, realistic wind motions on them.
Yeah..That!
Hi,
QuoteSpeaking of noises, I found this site. Just think of what could be possible for terrains.
http://www.neilblevins.com/cg_education/procedural_noise/procedural_noise.html
Out of curiosity and also user need, I'm would like to know why we only have the * relatively* few noise shaders that we do? I mean on a practical level, is it hard to make these?
Really you can do just about anything with what we have, but it can be a lot of work to get something square from something that is circular to begin with. So I would guess that having more options would make things faster (creatively). And I suppose that is why people have been talking about it. But as I said, what I don't understand, is why we don't already have more?
I also wanted to add (based on another resent thread) the request for object blur, in addition to "better"(?) object sequence support. Which was brought up by Matt, who surly knows better than I. But now that IM aware of it, I definitely want it.
(edit)
Oh, but I also just leaned that you cannot have motion blur on object sequences. Well that just kills some stuff I wanted to try. I guess that compositing is just the best way to do everything?
But now I'm back to masking and rotoscoping plants in the forground so I can have characters in the midground. And masking 24fps -30fps with a moving camera is just such a pain in the ass.
Oshyan-
Your explanation of 'simulating' the classic sculpture feature was excellent + + +. This was an example of the material that should be available in a transition guide or other documentation. That approach fits my bill exactly for creating a scene for other models.
3DS was just one I know of to serve as a transition between Cinema4D and TG. As I mentioned in another post, transition errors occurred due to 'operator error' rather than format problems.
Ed
We'll be putting out a video on the Painted Shader that demos some of the great things you can do with it.
For interfacing with C4D, I would *strongly* recommend OBJ format.
- Oshyan
Planetside seems to dodge/evade the noise flavor discussion in this topic, completely?
Why is the issue of wind not given any serious consideration? Is there already a way to do it without a dedicated function for it? Or is it simply too difficult for the way that Terragen has been set up? That, and some more advanced animation features are really the only things keeping Terragen from being the perfect landscape renderer, especially after the 3.0 and 3.1 updates.
Well, on wind, MAtt said he wanted to add this. So Im sure he will in time. But I don't mind waiting till after planetside finishes the other things they are woking on. THough I do agree with the things you are saying. TG is already a lot more than a simple terrain generator. And if they did not have big plans for the future, why would they have made it so open and robust in the first place? Heres hoping!
Would also second Martin's observation. But I suspect that the only reason Oshyan has not responded already is because the update is looming.
Its funny to see planetside's screen names pop up in blue in the active user list for a few seconds a day. The update could be here at any moment!.. it feels like.
We definitely *have* given wind functions consideration. No other program that I'm aware of can do realistic "wind" on *non-procedural* objects in large numbers of instances. In other words, if you import a standard OBJ into any other program and create a large number of instances of it (with e.g. Vray Scatter), you can't do wind on it realistically. You could do geometry deformation procedurally, which you can do in Terragen 3 now with the "Mesh displacer" input for all imported objects, but this affects the whole object and that's pretty unrealistic, for example the same magnitude of motion on a trunk vs. a branch vs. a leaf. The effect can be masked by e.g. height for a more realistic look, but it's still of limited realism, and that's all any other program would be able to do. The issue of actually creating realistic wind animation on arbitrary imported objects is quite challenging. Lacking a system to determine the "stiffness" of individual elements, how do you make it realistic? It's something we want to look at and hopefully resolve in the future, but it's certainly a challenge, not something that will come easily.
- Oshyan
At least from my experience and workflows available to people in my area of work, at the very least being able to import geo cache sequences of wind deformed trees done out of say Speedtree would be very beneficial. I don't expect TG to be able to do the deformations themselves, but it seems rather trivial by comparison for TG to be able to import these alembic type caches, offset them as needed and populate it all around your terrains. Maybe that is more involved but it seems simpler than actually having TG perform the displacements and would go a long way towards getting TG more entrenched in production workflows.
Yes, we do plan to support Alembic in the future. Allowing for multiple sequence offsets would be great but I don't know how challenging that would be.
- Oshyan
Regarding new noise functions, we do intend to add more at some point in the future. But we don't have a specific release date for that.
One of the things about TG's noise functions and their implementation to-date is they're not as simple as the basic forms you might often see out there, and this is in several respects. First, they've been setup and tuned specifically to work well in TG, both in terms of the rendering process, as well as the actual usefulness of the output (think for example of the way Lead-in scale vs. Feature scale vs. Smallest scale works). Second, additional controls and functions such as warping, etc. are usually added. Third, in some cases controls have actually been simplified for ease of use or removed due to implementation or compatibility concerns.
So when we contemplate adding new noise functions, if we're to make something that for example adds in to the Power Fractal, it has more considerations than just adding a simple off-the-shelf noise function. That being said, we're certainly thinking about simpler options as well, both for reasons of implementation speed, and allowing more simple use (think of a simple Perlin Generator, or the Voronoi Function Node except without requiring an input). But simpler is less powerful too. As I said, we're considering these various options for the eventual implementation of more noise functions, which we do have planned.
- Oshyan
Good to know thanks Osyhan
Thanks for the info, Oshyan.
Quote from: Oshyan on February 24, 2014, 06:38:07 PMYes, we do plan to support Alembic in the future. Allowing for multiple sequence offsets would be great but I don't know how challenging that would be.
I just upgraded to Lightwave 11.6 which says in its release notes that it supports Alembic Object/Cache Loading.
Hello, Planetside team!
First of all, let me say thank you for your efforts in creating such a nice tool for realistic worlds creation! I'm very inspired by what you're doing and your goals.
Yesterday I was watching your videos on Youtube and in one of them there was a question about using different objects in one population. You said that this is the direction you're working on, but you need more time to research on users' feedback regarding interface needs, triggers etc... So at that moment I thought that you can be inspired by Cinema 4D's Cloner Object which is actually works very good with any kind of populations with random (or organized) objects.
Thanks for the suggestion, p34, and welcome to the forum!
Matt
I'd love to have a small library of objects, presets, and plugins.
Kind of like TG 0.9 had back in the day. ;)
TG3 already has a small library of those things (well, except for plugins, which aren't available yet, but are coming). Free version users get access to the presets, including a few materials, sky presets, and a couple complete demo scenes, as well as some free objects from Xfrog and Silva3D. These are available on the free downloads page here:
http://planetside.co.uk/products/download-tg3
Licensed users have some additional downloads (mainly more plant models) available in the Downloads section of My Account in our online store.
- Oshyan