Waiting...................

Started by cajomi, May 26, 2007, 03:47:31 am

Previous topic - Next topic

Matt

Quote from: cajomi on May 29, 2007, 01:55:38 am
You know, some improvements are needed. Some of them are more work, some less.
So, what about an update?


Hi Cajomi,

I agree that the frequency of our updates has been very low, and I would sincerely like to improve that.

We have been working on quite a number of fixes over the last couple of months, some of which have involved some fundamental changes to code that could potentially cause lots of new unexpected bugs. It was important that we gave the alpha testers enough time discover these problems (of which there were some). The last thing we want to do is give our paying customers buggy software, and although we have fixed lots of bugs we have had to fix some new ones.

I do not believe that the current update delays are representative of how we will proceed over the coming months and years, although from time to time there may be periods where the particular focus of our development makes it more difficult to keep to a consistent update cycle.

Regarding the promise of more frequent development releases to pre-purchasers of the Deep version, I apologise for the embarrassing inconsistency between what we intended to do prior to the release of the Technology Preview and what we have been able to achieve so far. However, I believe we can improve that situation in the upcoming releases.

Thanks,

Matt
Just because milk is white doesn't mean that clouds are made of milk.

cajomi

Sounds very fair. Thank you very much!

Looking forward to that beast of software...
Developer of GeoControl

DeathTwister

I think you did and are doing just fine Jo. Your doing a great job. /bows don't let em get you down /winks. You did good.
DT
Maylock Aromy DeathTwister Stansbury
ATOMIX Productions

Matt

Thanks for the support.

I do think Cajomi and others have raised some important concerns, however. It's not our intention to mislead people or deliberately conceal information, but I recognise that often we don't make it clear enough to our customers what we're working on and why there are delays. I must admit that on a personal level I like to just get down and code, and then just release stuff when it's ready, but as a team we are all making efforts to formalise the process and improve communication with the users.

Regarding the usability of TG2, we're always listening to requests for changes and improvements. Having worked with the alpha testers on TG2 since 2004 I know that there are lots of very different ideas about how the interface should be improved, and often these ideas seem to contradict each other. We have had to plot a course through those (apparently) conflicting directions to arrive where we are today. It is still developing and evolving.

Whenever possible, if a suggestion seems to fit well with the overall direction that the software is headed we will do our best to incorporate it, even if it is not practical to make those changes immediately.

Cajomi, your "four week" estimate for the changes required to dramatically improve the user experience is very attractive. I would like to hear more about exactly what changes you think should be made according to such a plan. I did see your list of problems earlier in this thread, and I agree that they are problems we should try to fix, but it is not always clear how best to solve those problems in the context of the rest of the application. I welcome any specific solutions that you can suggest.

Regards,

Matt
Just because milk is white doesn't mean that clouds are made of milk.

latego

Quote from: jo on May 29, 2007, 12:21:39 am
You say something about things being a point and click in Vue and more work in TG2, populations were the example. I'm not surprised, Vue is considerably further along in its life. I think that you shouldn't confuse something like that with a GUI toolkit, because it isn't GUI toolkits that have anything to do with that. I hope you were just using it to illustrate a separate point.


Exact, I was meaning that when somebody else has done the grunt work, you can concentrate on app-related tasks.

Just to give you an example of how my mind works (or does not work... haven't decided yet...) in late 2005 it became clear that for future works for my customers (video surveillance companies) a scripting engine would be required. It spent 4 months searching for an appropriate tool. I did NEVER envision rolling out my own one... and on Christmas Eve 2005 I found http://www.lua.org/ (Blues Brothers light from the sky effect this time for sure!). In a few days I had a prototipical C++ wrapper ready (Lua has no canonical C++ wrappers; the existing ones are either too thin or too heavy, requiring a preprocessing phase) and in less than one month I could store everything I had done relating to scripting in the "closed case files folder" (Indiana Jones Ark of Alliance been rolled into a non descript government warehouse effect...)

A longer selection phase (unproductive I admit) enabled me to reach faster to the end result (if my clients had been more computer savy, I would have quickly gone the Scheme way but, as you can read in Lua architectural documents, Lua is a Modula like syntax plugged on an almost Scheme like core, so it is almost perfect!).

Bye and sorry if I upset you.

P.S.: if you are planning scripting for TG2, PLEASE have a look at Lua... you won't regret it.

Matt

Quote from: latego on May 29, 2007, 11:41:49 am
P.S.: if you are planning scripting for TG2, PLEASE have a look at Lua... you won't regret it.


We are planning scripting for TG2, yes. Lua was originally my first choice, but in the last 6 months I have been leaning towards Python due to its near ubiquity within the current crop of 3D applications. There is a huge potential to leverage existing scripts that are written for other 3D apps and adapt them to TG2.

Please, if anybody wants to continue a discussion of the merits of either Lua, Python or any other language for scripting in TG2, start another thread on the subject so that we don't dilute the current topic too much. Cheers!

Matt
Just because milk is white doesn't mean that clouds are made of milk.

cajomi

well,

I think, if the operators for height and size are added automatically, if a heighfield is imported, and if they would have standard values that match the way, the terrain is handled without them, it would make the whole process faster, without loosing any advantage of seperating them.

The alpha channel should be separated from the breakup, and be named "Alpha" or "Mask", and the this mask should have as standard size the size of the terrain and fit automatically. Changing the size of the terrain should be automatically change also the alpha. So, best way would be, to express the size a factors (10-0.1) of the original terrain.

I think, this should not make that much work.

The only thing, with my little expierence of TG2, is the camera. I understand, that is has its orientation to the univers, not to a planet. May be, it would simplify all, if you can choose at start up, or somewhere, to set the world as univers or a one planet world. In a one planet world, the old TG2 tracking should be possible. I did not like that camara tool at once, but the longer I used it, I found it more and more powerful compared to a 3D view.
If now placing of objects would be done in this preview (with a zoom please) it would be really simple work.

In general, it seems to me, that the naming could cause problems.
For creating a heightfield, why should I use shader, was the first I hought. Shader are for the terrain after it is created, for the rendering. And for what I need a "reflective shader" when I am creating a terrain?
On the other side, if now is time to shade, what does the alpine shader there, I found in it no colour or distribution.
So, I mean, if the functions appear only where they belong and are sensful and named the way they work, for example "layer", "map", "functions", "displacements" and are grouped, it would all be much easyer.
Four weeks sounds long for that, but that would be not so easy. I am sure, the naming is in your thinking exact how you want to name. And I am aware, that naming and expectations of naming depend on personal preferences and often also on the other softwares, which are used.

And that is all I meant. I have found with GeoControl, that sometimes simply changing the naming of a tool or control can enhace the acceptance dramatically and that every control should have a sensful start value.
Developer of GeoControl

Oshyan

Cajomi, these are potentially useful ideas. I think the biggest problem with what you suggest is that (sensibly, I think) masks and other image overlays operate in the Shaders group, coming after operations in the Terrain group, s surface shader nodes have no specific association with any terrain. I do think it would actually be very useful to be able to associate any given shader with a specific terrain or other shader so that you could potentially isolate its effect. Currently you have to use separate terrain paths and a merge shader to get this working and it's a bit clunky. I'm not sure of how easy that is to deal with "under the hood" as far as how TG2 handles displacement, etc. but I think it does make sense to aim for the possibility of assigning things per terrain or terrain shader. In any case I see that missing functionality as being the most difficult and time-consuming part of what you suggest. The rest seems fairly easy.

Additionally, as the most active representative of Planetside in the forums and fielding the majority of support through email as well, any issues with responsiveness and communication may rest in large part on me. However I feel like we have kept up well on issues and questions that are raised. We provide as much specific information as possible when for example questions regarding updates are raised.

You speak of your communications with the Vue or Carrara developers being more pleasant, but I've simply seen little or no attempts by you to communicate, at least to me, on the forums or otherwise (at least since some initial strong criticisms). It is our responsibility to keep our user base updated and we do that as best we can given the uncertanties of development. Given our past history of missed release dates I hope you will forgive us for being perhaps overly cautious in specifying release dates for updates now. But in any case if a user has a specific problem, question, or criticism it is up to them to express it so that we can respond. As much as we may be aware of many problems already and be working on fixes for them as time allows, it is also very helpful to hear from our users to know what *their* priorities are. So I encourage you to express your feelings more in the future, but before they get to the level of clearly deep frustration that set the original tone for this thread.

- Oshyan

rcallicotte

May 29, 2007, 09:17:47 pm #83 Last Edit: May 30, 2007, 11:36:49 am by calico
What I've noticed in this type of environment, where a programmer opens up his process to the end users, it's only the users who understand what is a priority to the programmer (in my actual work) who will have the greatest impact.  Criticism is rough and especially seems unreasonable when someone who has little to no understanding about my priorities gets my job confused with their priorities.

Starting with requirements, I don't change those until I have the base requirements completed and only then might I ask the end user's opinion. 

In Planetside's case, their requirements come from us (on this website) to some degree.  But, how Planetside prioritizes these seems to me to always be their call.  Always, in my opinion.  Otherwise, it's too many cooks in the kitchen.
So this is Disney World.  Can we live here?

cajomi

@Oshyan

thank you for making the problem so much clearer (with the shader nodes). I hope, this changing will be possible.

You are right, I did not take much part here. I simply have not the time. Hope this will change in autumn this year.
Developer of GeoControl

Oshyan

I know you're very busy with your own product and from the sound of it things are coming along very well. :) If you do ever have a question and no time or interest to post it here you are always welcome to email us either at support@planetside.co.uk or to one of our personal addresses. Your input is definitely valued.

- Oshyan

Matt

May 31, 2007, 12:16:20 am #86 Last Edit: May 31, 2007, 12:20:13 am by Matt
Quote from: cajomi on May 29, 2007, 12:15:52 pm
well,

I think, if the operators for height and size are added automatically, if a heighfield is imported, and if they would have standard values that match the way, the terrain is handled without them, it would make the whole process faster, without loosing any advantage of seperating them.


Yes, I can see that would make things easier for those kinds of operations. I am hesitant to add too many heightfield operators every time a heightfield is loaded, because there is always the question of which operators should get preferential treatment. But maybe scaling and vertical adjustment are the most important.

Quote
The alpha channel should be separated from the breakup, and be named "Alpha" or "Mask", and the this mask should have as standard size the size of the terrain and fit automatically. Changing the size of the terrain should be automatically change also the alpha. So, best way would be, to express the size a factors (10-0.1) of the original terrain.


I agree 100% that the Surface Layers need a separate alpha/mask (like the "blend shader" on some other shaders in TG2). The Fractal Breakup input was designed to give results similar to v0.9 surfaces with fractal noise, and is not a substitute for a dedicated masking input. The fact that the Fractal Breakup input can be used for this purpose has unfortunately lowered the urgency for adding a proper masking input.

Aligning image maps with a heightfield is slightly less trivial because a terrain may contain an arbitrary number of heightfields (or none at all). Not all users work with a single heightfield setup. Perhaps the Image Map Shader needs a new option that allows linking with a particular heightfield. This could be done in such a way that the connection is hidden from the network view to avoid clutter (in the same way that populators need to be connected to a planet but that connection is not drawn in the network view. I have considered linking image maps with heightfields already, but I have been waiting to see if I could find a more elegant solution.

Quote
The only thing, with my little expierence of TG2, is the camera. I understand, that is has its orientation to the univers, not to a planet. May be, it would simplify all, if you can choose at start up, or somewhere, to set the world as univers or a one planet world. In a one planet world, the old TG2 tracking should be possible. I did not like that camara tool at once, but the longer I used it, I found it more and more powerful compared to a 3D view.
If now placing of objects would be done in this preview (with a zoom please) it would be really simple work.


Orthographic views are on our to-do list, along with placement of objects in these views. I look forward to having these features, but I think these features alone would take more than 4 weeks to complete to a sufficient standard. They will probably come after render optimisations and multithreading.

Quote
In general, it seems to me, that the naming could cause problems.
For creating a heightfield, why should I use shader, was the first I hought. Shader are for the terrain after it is created, for the rendering.


I agree that there are many confusing names in TG2 right now. However, TG2's entire approach to rendering terrain of any scale and configuration means that it needs to use displacement shaders to create the terrain. I agree that using the word "shader" for displacement is somewhat confusing, but it is the same in most renderers that use displacement. In TG2 displacement and colour are often combined into a single shader to make it easier to achieve certain effects. For example the Fake Stones Shader.

Quote
And for what I need a "reflective shader" when I am creating a terrain?


Do you mean "why is it possible to choose Reflective Shader from the "Add Terrain" button?" I agree that's unnecessary, and maybe it would help if shaders were grouped according to whether or not they provide displacement (as you suggest below).

Quote
On the other side, if now is time to shade, what does the alpine shader there, I found in it no colour or distribution.


The Alpine Shader is a displacement-only shader, but it is still a shader according to the way that TG2 allows shaders to choose which kinds of modifications they perform on a surface. I hope this will be less confusing when we have better categorisation of the shaders.

Quote
So, I mean, if the functions appear only where they belong and are sensful and named the way they work, for example "layer", "map", "functions", "displacements" and are grouped, it would all be much easyer.


Agreed. Perhaps we can make this a higher priority in the coming months.

Quote
Four weeks sounds long for that, but that would be not so easy. I am sure, the naming is in your thinking exact how you want to name. And I am aware, that naming and expectations of naming depend on personal preferences and often also on the other softwares, which are used.

And that is all I meant. I have found with GeoControl, that sometimes simply changing the naming of a tool or control can enhace the acceptance dramatically and that every control should have a sensful start value.


I've always held those views too. For much of TG2's development lifetime the priorities have been different from those of v0.x because it was important to provide a lot of essential tools as quickly as possible for use in production, especially for things that v0.9 was never capable of. Of course a better user interface helps in every way but not if the underlying features are not there. This year we have to spend more time thinking about the UI.

Thanks for your input.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

cajomi

Thank you for this detailed comment.
Developer of GeoControl

Marcos Silveira

Give us water transparency, please!!!!!  :'(
I've been avoiding to render "waterscapes" cause the lack of it!!!

Adam Chrystie

I'm willing to wait for their releases.

Many of us chose to buy a "preview tech version". There was no mention of
being automatically entitled to alpha releases or being a tester.

Planetside has offerred a free version as well.

--Adam

--------------------
Adam Chrystie
3D Artist & Infrastructure/Pipeline Developer