|
|
Interface? Flexibility?
About Truespace Archives
These pages are a copy of the official truespace forums prior to their removal somewhere around 2011.
They are retained here for archive purposes only.
Interface? Flexibility? // Roundtable
Post by Nichod // Oct 28, 2006, 7:46am
|
Nichod
Total Posts: 10
|
My question involves the interface and how flexible IS it? For instance one of the things that has bothered me is the shader sliders with the large sphere's symbolizing the value of the setting. Can this be changed by the user?
Speaking of shaders. I am pretty sure that the DX9 shaders have a node based shading, but can the same be said of the standard truespace shaders?
Brian |
Post by Nichod // Oct 28, 2006, 11:45am
|
Nichod
Total Posts: 10
|
Also, I'm a bit concerned about the lack of compatibility between the realtime components and the rendering components. From what I've heard some of the realtime link editor created items don't work when rendered outside of the player. |
Post by TomG // Oct 30, 2006, 5:22am
|
TomG
Total Posts: 3397
|
Bear in mind that different rendering engines use different shaders. So what works in Lightworks will not work the same in V-Ray or VirtuaLight. What happens is that sometimes there are shaders that are "similar" and then if you render using engine A, tS will use such a "similar" shader if you swap to using engine B. This means that chosing "Phong" will rendering under Lightworks, and under V-Ray, though really the two are indeed using different shaders (ie different code).
The reason I mention the above engines is I think people find it easy to understand the difference in shaders between Lightworks and VirtuaLight say. That allows the next explanation - that the real-time render engine is also that, a separate, different, unique render engine. Just as a shader in Lightworks will not be the same as one in VirtuaLight, a shader for the real-time engine will not be the same as one for Lightworks.
In the same way, where a "similar" or "equivalent" shader exists, then it will be used. However, some DX9 shaders simply don't have an equivalent under Lightworks. For example, if you used the real-time Gooch shader. There is no Gooch shader under Lightworks (or VirtuaLight or V-Ray) and so there is no equivalent to use.
This is the same as there being Lightworks shaders that have no equivalent under V-Ray (the car paint shader, anisoptropic shader), or V-Ray having shaders not under Lightworks (Subsurface Scattering, Glossy Reflection). So basically this is true of all render engines - and because of that, it is true of the real-time engine too.
Note that these shaders are not in there for offline rendering purposes. They are there for real-time scenes. Equally important, those real-time scenes are intended for use as "final renders" - only you don't need to wait for them. You just use the option to save your real-time render, just as if you were rendering using Lightworks, or V-Ray. You then get a final image to use, which does of course feature all your DX9 and real-time shaders.
Note that the real-time quality can hit photoreal now, or very close to it (see some of Marcel's real-time work).
So this is the reason that the real-time view has shaders that don't appear the same in an offline render - it is a different render engine, intended not only as a preview of your scene, but sometimes as the final render itself!
Also note of course that the reverse has always been true - offline render engines usually have shaders that real-time can't duplicate (anything with raytracing such as reflection of transmission). So this difference is not in any way a "failing" or "shortcoming" of the real-time view. Previously of course, offlines had shaders real-time couldn't show, but the same was NOT true the other way around. It's true now because we have introduced the concept of using your real-time engine as the final engine, either for images and animations in the traditional sense, or of course as interactive scenes that other people will experience through the same engine (available free in truePlay).
On the Material Editor - not possible to change the spheres in the interface. However, changes are due to the ME.
HTH!
Tom
EDIT - there is a PS to the above. Link Editor created items can be either for the real-time engine, or the offline engine. So it is possible to use the LE to make shaders for each engine. Naturally, as mentioned above, these are different shaders for different engines and so will not carry across. You can (I believe) encapsulate shaders from different engines so that the shader has a different "version" of itself under each engine, though I haven't put that to the test. I do believe this is possible though, and done in some of the existing real-time shaders. Of course you then have to effectively write the shader twice. Maybe someone with more direct experience of shader dev in tS7 can comment?
HTH!
Tom |
Post by Nichod // Oct 31, 2006, 5:09am
|
Nichod
Total Posts: 10
|
Note that these shaders are not in there for offline rendering purposes. They are there for real-time scenes. Equally important, those real-time scenes are intended for use as "final renders" - only you don't need to wait for them. You just use the option to save your real-time render, just as if you were rendering using Lightworks, or V-Ray. You then get a final image to use, which does of course feature all your DX9 and real-time shaders.
I do hope this gets corrected. As when I view something in the 3D view I would prefer that it has a similar appearance to the rendered final output. I understand the intention of the player is to allow final rendering to take place there, but many things don't quite work perfectly in a realtime view yet. I appreciate the forward looking of caligari in regard to realtime rendering. Just hope that some compatibility is considered with shader building and the realtime preview.
Now I may be misunderstanding how it all works, so I'll put this question in. Can I then use the link editor to build a LW shader? And will it show an equivalent or as close as possible preview in the player? |
Post by parva // Oct 31, 2006, 6:06am
|
parva
Total Posts: 822
|
Can I then use the link editor to build a LW shader?
Yes but only the Super LW shader gives you a link editor interface.
And will it show an equivalent or as close as possible preview in the player?
Yes as far that there are equal shaders on the realtime site.
Standart shaders will be converted to realtime view like known but complex shaders or things which need raycasting can't be generated instantly.
Things like refraction/reflection must be faked. Currently the realtime view don't support this but this will come in the future.
DX shaders are for realtime only. They are optimized for this kind of realtime view. So that there are two ways - you can create a Realtime scene, best with use of DX shaders or you create a scene for rendering with software renderers like lightworks or vray and use the realtime view just as visual help (to see where the light casts shadows etc.) to build up your scene as always.
Both isn't possible yet because you have to optimize your scene for one or the other. Due to the fact that there are processes which aren't possible or very slow to create in realtime. |
Post by TomG // Oct 31, 2006, 8:05am
|
TomG
Total Posts: 3397
|
Yes, as noted, there is nothing to "correct" here. There are two different render engines, optimised for different uses. If you are using regular Phong, then sure, you'll find a real-time Phong and a Lighworks Phong, and the system does indeed currently use both so that real-time and offline render match.
But someone might write a clever DX shader for real-time appearance of Subsurface Scattering. Now, it will use all sorts of techniques that depend on DirectX, on PixelShader2.0, and on the hardware on your graphics card. All of which is different than what Lightworks has available. So there will be no equivalent - even V-Ray, which has a Subsurface Scattering shader, would not be equivalent as they will use different routines, shortcuts, clever techniques, etc, founded on their intended engine, and not available to the other engine.
As noted you COULD write some conversion routine that would read your input to one shader, and from the programmer's knowledge, would set approximations in the other shader to simulate it. However, this means a lot of extra work, and isn't really "broken" if it is not done.
So the real-time engine has two uses - one a preview of your scene to cut down on the need for test renders. And one as a separate engine in its own right. In both cases though it is really a separate engine, and can't guarantee having all the shaders from all other possible engines in it (just as all engines can't guarantee having shaders equivalent to the real-time engine, such as no Gooch under Lightworks).
There will always be a difference in an image when rendered under engine A and under engine B, and that includes the real-time engine too. The best that can be done is ensuring the real-time engine works well as a preview for the most important elements and shaders in the scene. If you choose to start using Gooch and other such DirectX shaders, then you have chosen to specialise for your real-time scene and can no longer expect the same results from the offline.
If you choose to introduce transmission and real reflections, then you have chosen to optimise your scene for the offline engine, and can no longer expect the same results from the real-time.
All we can ever do is get close :) And right now it is stunningly close, with lighting and shadows even, so you can get a very good preview of your scene instantly, without the need for a test render! Asking both real-time and offline to be identical, though, would mean crippling one to fit in with the other - ie you'd have to give up on Gooch and fancy real-time transparencies etc since they are not supported under Lightworks, and give up on transmission since it is not supported under real-time, which would not be good!
Instead, we leave it to the user to understand the shaders they are using, and choose which engine to exploit to the max (with the understanding they are moving away from the other engines in doing so).
HTH!
Tom |
Post by Nichod // Oct 31, 2006, 8:19am
|
Nichod
Total Posts: 10
|
Yes, as noted, there is nothing to "correct" here. There are two different render engines, optimised for different uses. If you are using regular Phong, then sure, you'll find a real-time Phong and a Lighworks Phong, and the system does indeed currently use both so that real-time and offline render match.
Sorry if that came off wrong. I merely wasn't sure if the realtime preview of the final output was going to be similar or even possible. Didn't necessarily mean something was broken.
All we can ever do is get close :) And right now it is stunningly close, with lighting and shadows even, so you can get a very good preview of your scene instantly, without the need for a test render! Asking both real-time and offline to be identical, though, would mean crippling one to fit in with the other - ie you'd have to give up on Gooch and fancy real-time transparencies etc since they are not supported under Lightworks, and give up on transmission since it is not supported under real-time, which would not be good!
I suppose its my mindset, I'm always going to wish to render to final output and thus would like there to be a consistency between the realtime preview and the offline rendering options. For example in my current application I apply a shader and adjust it accordingly. The realtime preview gives its best approximation of the shader I'm using. From what I'm getting this is mostly available. The advantage of a clear and nearly exact realtime preview of a scene is appealing.
Yes but only the Super LW shader gives you a link editor interface.
Could this be elaborated on? Perhaps with some screenshots of examples.
One suggestion I have to the marketing and web design team for Caligari is to show more clear and specific examples on the TS7 product page. Most of the images show me little useful info. A fine example is the video training freebie demonstrating the ability to change the manipulator. More examples of things like that would be more beneficial to buyers.
For instance this http://www.caligari.com/products/trueSpace/ts5/Brochure/magicring.asp demonstrated via a small gif. The description "Use the Magic Ring widget to draw 2D and 3D primitive shapes interactively in your workspace." does not tell me much, how does it draw and what does this do?
Just some suggestions from a possible buyer looking to upgrade. Take them with a grain of salt if you so wish. I appreciate the responses here. |
Post by TomG // Oct 31, 2006, 8:38am
|
TomG
Total Posts: 3397
|
Nope, didn't come off wrong! I too would love it if the preview was an identical match to the render, and if a shader in Lightworks worked identically under V-Ray etc.
And we do aim for that as much as is possible. Where there are common shaders, we have that "connection" between the two - so if you use Phong, you will get similar results in real-time, Lightworks, Virtualight and V-Ray. Each one has a Phong shader, and the settings are passed to each, so you can switch engines and get something close.
So where possible so far, that's in place, and we'll keep working on that. We will also keep working on the real-time display to make it ever more useful as a preview, as well as more useful on its own - both uses are kept in mind :)
The long technical waffle was just to give some picture of what goes on behind the scenes, and why it will never be possible to get an identical render, or preview even. But that doesn't stop us for aiming to get it close! :)
Thanks for the web page feedback too - we are indeed thinking of more things like the video example that you mention, though it will take time I would say, but those will become more and more prevalent over time!
HTH!
Tom |
Post by tSplorer // Nov 2, 2006, 5:04pm
|
tSplorer
Total Posts: 27
|
For instance this http://www.caligari.com/products/trueSpace/ts5/Brochure/magicring.asp demonstrated via a small gif. The description "Use the Magic Ring widget to draw 2D and 3D primitive shapes interactively in your workspace." does not tell me much, how does it draw and what does this do?
Gotta admit that tS 6.6 has lots of interesting stuff in there. Problem is, they're just seem interesting. Stuff that have no real value in the grand scheme of things. It would appear that they add them just to attract new users, or use them for promotional purposes. I'd really like to see a coherent and consistent workflow. Add features that are really necessary such as the constraints and inference Caligari is working on this time. Things that speed up the process, not just things that look good on ads. |
Post by tSplorer // Nov 2, 2006, 6:58pm
|
tSplorer
Total Posts: 27
|
Also, you might have noticed that nowadays 3d developers are in the business of streamlining their apps most notably the newer ones such as Hexagon and Silo. No magic rings, no nurbs, etc. Just features necessary to achieve clear-cut modeling. It may be hard to eliminate these tS unnecessary features because it might offend those who do use them, but it's something Caligari worth or should start considering: STREAMLINE, STREAMLINE, STREAMLINE. Take the best and tested method seen in Hexagon, Silo, SketchUp, Rhino, Max, etc. and assemble them in tS next upgrade or version. |
Post by Nichod // Nov 3, 2006, 5:40am
|
Nichod
Total Posts: 10
|
Also, you might have noticed that nowadays 3d developers are in the business of streamlining their apps most notably the newer ones such as Hexagon and Silo. No magic rings, no nurbs, etc. Just features necessary to achieve clear-cut modeling. It may be hard to eliminate these tS unnecessary features because it might offend those who do use them, but it's something Caligari worth or should start considering: STREAMLINE, STREAMLINE, STREAMLINE. Take the best and tested method seen in Hexagon, Silo, SketchUp, Rhino, Max, etc. and assemble them in tS next upgrade or version.
On some level that is true. But I don't think TS current features are bad, just that some of them could be consolidated. Caligari does appear to be redesigning the workflow and reworking things, I expect we will see many changes. I'm holding off for a little bit to see if TS holds what I am looking for. I want to upgrade, but the previous 2 upgrades I did were a waste and just more of the same, not containing the features I really wanted or features that were not implemented as I expected. |
Post by TomG // Nov 3, 2006, 8:49am
|
TomG
Total Posts: 3397
|
"Gotta admit that tS 6.6 has lots of interesting stuff in there."
A little confused, as I thought we were discussing tS7?
Anyway no feature has ever been added to look good on ads. The magic ring is all about making things quicker and easier and streamlining. The concept is being able to change parameters when you create a primitive without needing to wander off to a set of dialog boxes - want more sides, extra edges, taller? You can do it without the need to find an extra icon, or open up a settings box, you just click to create the primitive, and then adjust those details right under your mouse.
Now, some don't like that, and some do. A matter of taste. But the reasoning is certainly sound - if you don't need to drag your mouse off elsewhere to change those parameters, then it should indeed be streamlining :)
Other streamlining issues are happening of course, for instance the new methods of sweeping faces. Streamlining is also now possible in the way that a user wants it, since the interface is customisable. Do you hate 3D widgets? Turn them off and make background widgets or hotkeys to replace them. Do you love 3D widgets and wish there was one that did "function x" - then create a new 3D widget to do just that.
After all, everyone has a different workflow, and there are those for whom method a is ten times faster, and those for whom method a is ten times slower. All depends on how they think and work.
So I think customisability is the way of making workflow streamlined for as many people as possible :)
All the comments above refer to tS7. If we are talking about tS6.6, then the reasoning behind the interface is the same, but there is no further advancement happening on streamlining it, and no customisability in the interface.
HTH!
Tom |
Post by Nichod // Nov 3, 2006, 4:24pm
|
Nichod
Total Posts: 10
|
"Gotta admit that tS 6.6 has lots of interesting stuff in there."
A little confused, as I thought we were discussing tS7?
I was treating it as a TS7 discussion. I'm not sure why he/she went off about TS 6.6. My main concern with TS and my reasoning between waiting to upgrade is that many of the cool tools do work well, but do not work smoothly together. Thats something that is changing within version 7 and hence my interest.
One thing I am curious is if the new skeleton/rigging tools will offer the flexibility present in other programs. For example, the rig linking in with the link editor so expressions could be used to create linkings within a rig, with expressions driving movements, etc.
Anyway no feature has ever been added to look good on ads. The magic ring is all about making things quicker and easier and streamlining. The concept is being able to change parameters when you create a primitive without needing to wander off to a set of dialog boxes - want more sides, extra edges, taller? You can do it without the need to find an extra icon, or open up a settings box, you just click to create the primitive, and then adjust those details right under your mouse.
I doubt that. But I get what you are getting at, the feature isn't added merely for show. I think the magic ring is a great tool. I'm curious can its design be edited within the new architecture?
I wish I could see the new implementation of bones in greater detail. Waiting for the next blog entry. |
Post by tSplorer // Nov 4, 2006, 12:44am
|
tSplorer
Total Posts: 27
|
A little confused, as I thought we were discussing tS7?C'mon, let's admit that there hasn't been a drastic difference between version 6.6 and 7 when it comes to modeling.
Anyway no feature has ever been added to look good on ads.
Maybe. Maybe that was not the real intent. It's possible that one of your coders came up with something cool, then everyone thought it should be added as a nice cool feature.
The magic ring is all about making things quicker and easier and streamlining. The concept is being able to change parameters when you create a primitive without needing to wander off to a set of dialog boxes - want more sides, extra edges, taller? You can do it without the need to find an extra icon, or open up a settings box, you just click to create the primitive, and then adjust those details right under your mouse.You didn't actually streamline it. You just made it more complex. A newcomer would think that it's use is so precious that he begins to think of spending a lot of time with it when in fact you could start from a mere cube! C'mon. (Actually, dialog boxes seem more useful because the usual input fields are the only ones we ever need. You add a cube, for example. In some cases all we want is fillet or chamfer its corners. Then the height and width, which could be manipulated with a widget manipulator. What else? All the extra ones are unnecessary. Do we need magic rings for that?) They're supposed to be aids to make the modeling process smooth. They're more of a distraction. 3d is not for kids who fiddles with anything they can touch. It's for adults to make something that lasts like a piece of art. Sure, it's cool to play with features like the magic rings for a while, then reality sinks in: you don't really need 'em.
The magic rings are just among the many unnecessary features tS has. I could identify them very accurately, but I don't have a lot of time going back to them and put them on paper. You should be able to.
Now, some don't like that, and some do. A matter of taste. But the reasoning is certainly sound - if you don't need to drag your mouse off elsewhere to change those parameters, then it should indeed be streamlining :)A famous shrink on tv constantly say in his show, "You cannot change what you don't acknowledge." I understand that you're still selling your bread and butter. Any hint of negativity makes potential customers shy away from your products. But you are in the software industry. You cannot possibly be perfect. No one else is, even the big ones. You should welcome suggestions.
Other streamlining issues are happening of course, for instance the new methods of sweeping faces. Streamlining is also now possible in the way that a user wants it, since the interface is customisable. Do you hate 3D widgets? Turn them off and make background widgets or hotkeys to replace them. Do you love 3D widgets and wish there was one that did "function x" - then create a new 3D widget to do just that.
After all, everyone has a different workflow, and there are those for whom method a is ten times faster, and those for whom method a is ten times slower. All depends on how they think and work.
Exactly. If you want to bring a substantial amount of users in your base, then, imo, one of the keys is extensive customization feature. They should be able to bring their usual habits and practices from their "home" applications to yours so the transition will not be painful. You don't question habits. You adapt. You want a Maya interface? I have one for you. You want a Hex UI? I also have one for you. Software developers now make it a point to make their apps compatible with the mainstream app. This is happening not just in the 3d industry. Corel, for example has an answer to MS Word: WordPerfect. It's looking more and more like one. So its Paint Shop Pro, CorelDraw Suite. Parametric solid modelers like Solidworks and Autodesk Inventor have almost the same UI and workflow, yet still preserve their identities.
So I think customisability is the way of making workflow streamlined for as many people as possible :)
All the comments above refer to tS7. If we are talking about tS6.6, then the reasoning behind the interface is the same, but there is no further advancement happening on streamlining it, and no customisability in the interface. |
Post by Nichod // Nov 4, 2006, 7:30am
|
Nichod
Total Posts: 10
|
C'mon, let's admit that there hasn't been a drastic difference between version 6.6 and 7 when it comes to modeling.
I'd disagree there. We have a new SDS implementation. Soft selection. New methods of selecting. A new realtime implementation that allows for better visualization while modeling. Included with that is better optimization in how TS handles polycount, so in theory you can have very levels of subdivision. Procedural based modeling. Collaboration mode for modeling. I believe the command history is new as well. Though with that one I could be wrong. And in 7.5 more will be added like the example of sketchup style modeling.
Not to mention simple things like being able to customize the interface more to improve your modeling workflow. Things like changing widgets for specific tasks, etc.
You didn't actually streamline it. You just made it more complex. A newcomer would think that it's use is so precious that he begins to think of spending a lot of time with it when in fact you could start from a mere cube! C'mon. (Actually, dialog boxes seem more useful because the usual input fields are the only ones we ever need. You add a cube, for example. In some cases all we want is fillet or chamfer its corners. Then the height and width, which could be manipulated with a widget manipulator. What else? All the extra ones are unnecessary. Do we need magic rings for that?)
I don't agree with that at all. I think it all depends on what you are modeling and the modeling technique you are using.
...but I don't have a lot of time going back to them and put them on paper.
I think a list of things would be good for caligari to see. I'm sure they can't read the minds of there userbase. They can only change and adapt what they hear about.
Anyway. I do hope more information is updated on the product page. Currently I don't see enough to warrant an upgrade. |
Post by tSplorer // Nov 4, 2006, 8:35pm
|
tSplorer
Total Posts: 27
|
Like what I said in the other thread I started, I like what I see in Roman's blogs, especially the SketchUp-style inference and push and pull. I'm definitely sure that tS's next upgrade will be the talk of the whole CG community when it comes out. Afaik, not one from among the mid to highend 3d apps has ever thought of implementing it. I don't really know why when it's always been a feature of most CAD programs as well as parametric solid modelers. It's the most natural way to draw in 3d space. Direct manipulation at its best using only one viewport. You know exactly where your entities are going with the aid of inference guides. I can't wait to play with tS 7.5 :) |
Post by tSplorer // Nov 5, 2006, 7:26am
|
tSplorer
Total Posts: 27
|
I'm sure everyone who have visited Roman's Blogs have seen this:
http://forums1.caligari.com/DL/PE3.rar
This is brilliant. I just don't know what more you want to add after this feature is implemented perfectly. Seems it's got everything in it: powerful constraints a.k.a. inferences without having to press X, Y or Z to make sure you are going in the right axis or at a certain angle; snapping features are also there as well as the most used feature of them all -- extrude normal, which is the equivalent of SketchUp's push and pull. It's just so common sense that it makes you wonder why the others are not doing something about it.
BTW, I hope there is also an option to change the direction of the axis manipulator not just in the usual axis directions. There are lots of cases where you want to move an entity that is not parallel to any of the three axes. In other words, make sure that you not only work on regular angles such as 90, 180, 360, 0. Kind of like SketchUp's protractor.
Also, I've always been curious about the possibility of not using any subdivision levels to come up with something. SketchUp could come up with beautiful drawings without it. It's not even NURBS. I don't know how to describe it. All these brilliant features that are now being worked on such as inference and constraints don't necessarily apply to polygon/subd modeling such as in the area of organic modeling. You don't necessarily need inferences for organics. Seems mechanical and architectural will be the main beneficiary. Or perhaps animation such as camera angles, paths, etc. Hmmm... I just have to gather my thoughts and organize them. More later... |
Post by tSplorer // Nov 5, 2006, 8:15am
|
tSplorer
Total Posts: 27
|
I think I know what I've been kind of suggesting. There must be a way to implement booleans and fillets using polygons, as opposed to NURBS. We know they are perfect using NURBS. For example, a polygonal cube with beveled or filleted corners is a finished model, assuming that's just what we wanted to do. Yet it's got ZERO subdivision level. (This is exactly what SketchUp is.) There ought to be a way to implement non-NURBS booleans without having to contend with messy meshes. I think the remedy is to set a certain standard such as using booleans only at subd level 2, or 3 if you want it smoother. OR set the option only at rendering time. At modeling time subd levels could be ignored and try to figure out an alternative like setting something for representation purposes only. A circle, for example doesn't have to be in a high resolution mode, but when rendered it could be a perfect circle. Something like that. Bottom line is, booleans don't have to be tied in with subdivision levels.
And I think that's where the confusion is. Do I make some sense? I think this calls for a feature INDEPENDENT of all the other features. Kind of like a SketchUp within the 3d app, but with more sophistication such as booleans and fillets. It's non-NURBS.
Anyhow, it may be something to think about in the next higher versions.
EDIT:
I'm not even sure if I'm making any sense. SketchUp, as I thought about it, has booleans except that they are done kind of manually. You draw a rectangular surface or a cube, for example. You don't need to draw a cylindrical object to punch a hole on the cube and apply a boolean difference. All you do is to draw a circle at one of the cube's surfaces, then apply a push and pull operation, which is the equivalent of a boolean difference. I think what needs to be implemented is accurate filleting operations to smooth out corners. SketchUp developers may be going in this direction. I don't know. IT SEEMS complicated especially with non NURBS. So, you might want to brush aside these last posts of mine. ;-) till they make sense. |
|
