Roadmap

Started by amandas, June 18, 2020, 03:57:59 AM

Previous topic - Next topic

Kadri

Quote from: Matt on June 23, 2020, 05:29:22 AM
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).
That is nice Matt.

amandas

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
Artist / Developer
open for freelance / full project cycle
http://arturmandas.com

Jo Kariboo

Quote from: Matt on June 23, 2020, 05:18:06 AM
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.

Thank you!