Hi there,
is there a roadmap of any level of complexity available? I would like to know what the future brings in the realm of the most photo-realistic landscape renderer on planet Earth ;)
Best
Hi Artur, and welcome to the forum!
It's been requested a few times recently, so I've put this together:
https://trello.com/b/RqyLUVGw/terragen-public-roadmap
The link might be temporary.
This is a very cut-down list, intentionally. If something doesn't appear in the lists it could still be on our internal private roadmap.
Hi Matt,
thank you very much, it is great that you work on OCIO and PBR workflow. I am also curious about the mysterious TG5 R&D ;)
I was thinking on the feature wishlist in my head, and the main areas I feel could profit from improvements IMHO are:
a) UX
b) scene assembly & external asset support
c) viewport "smoothness"
d) documentation and ease of access.
Since TG uses unique, progressive viewport rendering that is view-dependent, and relies almost 100% on procedural content generation, I would use these "limitations" as advantage, namely:
a) Why not progressively render large .objs with no maps, a bit of UE5 style, virtualizing assets (like the terrain is, auto-LODing? on-the-fly?) If not possible to do streaming large objects, cache it once in the BG, autosaving results in a TG edible format (I think Clarisse does the similar thing).
b) Why not give an option to stream populated object at runtime without full import + maybe low-poly proxy for preview purposes (it is imported only for the preview, .tgd are simple ASCII plain text files)? It would be good to have the materials of external assets auto update if that asset changes (polygons do update).
c) Why not cache already generated viewport preview (pixels mapped to a sphere with certain resolution), so that the user has faster feedback (cached content can be marked greyish to indicate possible inaccuracy and rendered as an underlay)?
d) maybe drop Mac support at all? What is the user base here? For small dev team I can imagine how costly it can be to maintain the project, double the dependency hell. Besides, Apple will be replacing Intel CPU with their own making in the coming years, so I guess even harder to maintain cross-platform interoperability.
These are some ideas which you might find helpful, maybe some of these are already somewhere, still learning this great soft.
Best regards
Quote from: amandas on June 19, 2020, 08:14:30 AMa) Why not progressively render large .objs with no maps, a bit of UE5 style, virtualizing assets (like the terrain is, auto-LODing? on-the-fly?) If not possible to do streaming large objects, cache it once in the BG, autosaving results in a TG edible format (I think Clarisse does the similar thing).
Can't you activate objects with no shaders? That's an object with no maps. More distant objects will use billboard like cutouts too
Quote from: amandas on June 19, 2020, 08:14:30 AMd) maybe drop Mac support at all? What is the user base here? For small dev team I can imagine how costly it can be to maintain the project, double the dependency hell. Besides, Apple will be replacing Intel CPU with their own making in the coming years, so I guess even harder to maintain cross-platform interoperability.
Honestly, yes. There is no dedicated development team for this, it's builds behind, and yes Apple is beginning to move to the Bionic processors as early as this month. I feel sorry for those that are on Mac to begin with. Such gimmicky systems that abuse hardware past their EOLs. My friend recently just sold his cheese-grater for a AMD Threadripper because he claims the performance was half a decade out of spec.
Also Mac has yet to unveil 3d editing and stuff on the iPads (bionic), and I feel this productivity is going to be inherently inhibited, even on desktop. The chipsets are still fundamentally weak and meant for specialized tasks.
Dropping Mac support? That would mean that the 12 years of hard work I invested in Terragen would be wasted. I'd better quit right away then. It's a consolation that you feel sorry for me, WAS.
Quote from: René on June 20, 2020, 04:47:44 AMDropping Mac support? That would mean that the 12 years of hard work I invested in Terragen would be wasted. I'd better quit right away then. It's a consolation that you feel sorry for me, WAS.
I understand. Though I already feel the last 10 years have been a waste. Development is at a crawl, and the things many people need for their jobs is still missing, and because if limitations I did not know about I've even lost contracts, and it's hard to pick any up with this software. TG still being heavily a internal sandbox where everything is stuck in it, is a big one. If it's going to be so hard to use TG because unless composing layers, you are stuck in it, much works needs to be done on the tools people need.
As is, from lots of talks, and my own experience with pro license, the maintenance renewal is a rip off. Nothing happens during your license period to warrant such a cost. If someone isn't aware of the long track record of little substantial updates, and mostly changing wording and layout and bug fixes not properly tested for, of course they would pay. A lot of consumers do their research though. It would be nice if the maintenance reflected the actual work put into the software that year, or simple was ditched. Keep expensive perpetual licenses and move to subscription for entry level and those that may not stick around which is probably a majority of users passing by unfortunately. He'll get much better monthly funding and still annual funding in large portions.
Subscription model is mainly based on a promise. But I prefer to pay for what I get when I fork the money. This is the reason I always try to buy perpetual licenses. There may be advantages in subscription but honestly I prefer to pay an update the next year because it's worth the price. If an update comes.
That said, I recently purchased a TG Pro perpetual... I had the sensation monitoring the product from time to time that it has a slow development cycle and I guessed that this is because maybe developers are involved as artists/consultants in TG related projects so they have another income, and this slows down the development.
As a new user I obviously hope TG has a bright future but, as said, I paid for what I got when I paid and from this point of view i'd be (sadly) fine also if TG development will stop.
All that said because after reading about the crawling Mac development, I hope that at least Windows development will go on, and to fork some money for next year update :)
I may be wrong and if so, I'm sure I'll get corrected quickly, but I believe one doesn't have to purchase a maintenance renewal at any certain time. Wait until you believe there's enough updates to justify it for you (not sure how it works for a unit version, like v4 to v5.)
Quote from: uuderzo on June 20, 2020, 09:09:30 PMSubscription model is mainly based on a promise. But I prefer to pay for what I get when I fork the money. This is the reason I always try to buy perpetual licenses. There may be advantages in subscription but honestly I prefer to pay an update the next year because it's worth the price. If an update comes.
...
...I paid for what I got when I paid and from this point of view i'd be (sadly) fine also if TG development will stop.
...
Exactly. I learned that from Lightwave and think the same way about any software since years.
Quote from: jaf on June 21, 2020, 04:26:52 AMI may be wrong and if so, I'm sure I'll get corrected quickly, but I believe one doesn't have to purchase a maintenance renewal at any certain time. Wait until you believe there's enough updates to justify it for you (not sure how it works for a unit version, like v4 to v5.)
I think for major versions you pay extra around 50 bucks over the maintenance fee (judging from the website; v3->v4). I was also curious whether there is a penalty for non-continuous maintenance, and it looks like there is not, which is fair, IMHO.
Quote from: Matt on June 18, 2020, 10:59:31 AMThis is a very cut-down list, intentionally. If something doesn't appear in the lists it could still be on our internal private roadmap.
well for me the happiest announcement for me was. "Grouping"...been hoping for that since forever...thanks
Thank you for the feedback and questions.
Quotea) Why not progressively render large .objs with no maps, a bit of UE5 style, virtualizing assets (like the terrain is, auto-LODing? on-the-fly?) If not possible to do streaming large objects, cache it once in the BG, autosaving results in a TG edible format (I think Clarisse does the similar thing).
Do you mean large in terms of screen space or large in terms of the file? What is your workflow with these files, and what problems are you encountering?
Quoteb) Why not give an option to stream populated object at runtime without full import + maybe low-poly proxy for preview purposes (it is imported only for the preview, .tgd are simple ASCII plain text files)? It would be good to have the materials of external assets auto update if that asset changes (polygons do update).
Are you finding that OBJs are slow to load, or slow to preview, or is there some other problem? Have you tried previewing in RTP mode? The RTP much faster at rendering large populations. LOD doesn't give you the same level of speedup in a ray tracer that it does in a rasterizer, and because populations use instancing there isn't any improvement in memory use by LOD'ing - in fact it is the opposite.
Quotec) Why not cache already generated viewport preview (pixels mapped to a sphere with certain resolution), so that the user has faster feedback (cached content can be marked greyish to indicate possible inaccuracy and rendered as an underlay)?
I have considered doing this. After adding RTP it seemed to be unnecessary for vegetation/imported models. For procedural/subdiv terrain we still need a better caching and previewing solution, and I am working on this for Terragen 5.
Quoted) maybe drop Mac support at all? What is the user base here? For small dev team I can imagine how costly it can be to maintain the project, double the dependency hell. Besides, Apple will be replacing Intel CPU with their own making in the coming years, so I guess even harder to maintain cross-platform interoperability.
It is a much smaller user base but our current plan is to continue supporting the Mac.
Quote from: amandas on June 21, 2020, 08:09:10 AMI think for major versions you pay extra around 50 bucks over the maintenance fee (judging from the website; v3->v4)
Now that Perpetual licenses are on a Perpetual + Maintenance model, there won't be any extra cost in going from 4.x to 5.x, it will just require up-to-date maintenance:
https://planetside.co.uk/faq/#maintenance-policy
Quote from: jaf on June 21, 2020, 04:26:52 AMI believe one doesn't have to purchase a maintenance renewal at any certain time. Wait until you believe there's enough updates to justify it for you (not sure how it works for a unit version, like v4 to v5.)
That's correct, and 5.x will just be another update. Terragen 4 license owners will be able to get Terragen 5 by updating their Maintenance at that time (if it expired).
Quote from: Matt on June 23, 2020, 05:29:22 AMQuote from: jaf on June 21, 2020, 04:26:52 AMI believe one doesn't have to purchase a maintenance renewal at any certain time. Wait until you believe there's enough updates to justify it for you (not sure how it works for a unit version, like v4 to v5.)
That's correct, and 5.x will just be another update. Terragen 4 license owners will be able to get Terragen 5 by updating their Maintenance at that time (if it expired).
That is nice Matt.
Quote from: Matt on June 23, 2020, 05:18:06 AMThank you for the feedback and questions.
Quote from: undefineda) Why not progressively render large .objs with no maps, a bit of UE5 style, virtualizing assets (like the terrain is, auto-LODing? on-the-fly?) If not possible to do streaming large objects, cache it once in the BG, autosaving results in a TG edible format (I think Clarisse does the similar thing).
Do you mean large in terms of screen space or large in terms of the file? What is your workflow with these files, and what problems are you encountering?
Quote from: undefinedb) Why not give an option to stream populated object at runtime without full import + maybe low-poly proxy for preview purposes (it is imported only for the preview, .tgd are simple ASCII plain text files)? It would be good to have the materials of external assets auto update if that asset changes (polygons do update).
Are you finding that OBJs are slow to load, or slow to preview, or is there some other problem? Have you tried previewing in RTP mode? The RTP much faster at rendering large populations. LOD doesn't give you the same level of speedup in a ray tracer that it does in a rasterizer, and because populations use instancing there isn't any improvement in memory use by LOD'ing - in fact it is the opposite.
Quote from: undefinedc) Why not cache already generated viewport preview (pixels mapped to a sphere with certain resolution), so that the user has faster feedback (cached content can be marked greyish to indicate possible inaccuracy and rendered as an underlay)?
I have considered doing this. After adding RTP it seemed to be unnecessary for vegetation/imported models. For procedural/subdiv terrain we still need a better caching and previewing solution, and I am working on this for Terragen 5.
Quote from: undefinedd) maybe drop Mac support at all? What is the user base here? For small dev team I can imagine how costly it can be to maintain the project, double the dependency hell. Besides, Apple will be replacing Intel CPU with their own making in the coming years, so I guess even harder to maintain cross-platform interoperability.
It is a much smaller user base but our current plan is to continue supporting the Mac.
Hi Matt,
sorry for delay, 2 kids ;) This is more of a wish list to improve productivity, not a problem list :) I have tried to pin point several areas I am only guessing (unaware of the code base) that might be good to implement taking into account TGN is a largely procedural piece of software.
Ad. a) yes, I mean screen space. I mean sort of tricks to extrapolate looks based on progressive viewport render (hope this makes sense), to avoid preloading. Use case: photogrammetry models, no maps, only vertex colors.
Ad. b) I meant here mainly the situation when I need to update the external asset. It looks like the mesh is correctly updated, but shader networks are created at import, and if I change materials, I need to reimport (please correct me if I'm wrong here). I really like that TGN scene files are plain ASCII files, so there seems to be potentially flexibility as far as external assets are concerned. If there was a button to update the shaders (maybe with a warning and backup request etc.), maybe it could save some work. What do you think?
Ad. c) I meant mainly terrains here. I love RTP, it's great and super fast, the thing is that it looks like it is based on the current level of terrain generation in the viewport (as much as I can tell).
Ad. d) Great! Thumbs up!
Ad. e) Sure thing, just my five cents on possible routes of development :)
Best regards
Quote from: Matt on June 23, 2020, 05:18:06 AMQuote from: undefinedd) maybe drop Mac support at all? What is the user base here? For small dev team I can imagine how costly it can be to maintain the project, double the dependency hell. Besides, Apple will be replacing Intel CPU with their own making in the coming years, so I guess even harder to maintain cross-platform interoperability.
It is a much smaller user base but our current plan is to continue supporting the Mac.
Thank you!