VRay? DX9? LW? How about one material type does all?

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.

VRay? DX9? LW? How about one material type does all? // Feature suggestions

1  |  

Post by om1nous // Jun 15, 2007, 10:38am

om1nous
Total Posts: 0
This is just a suggestion derrived from being a noob.


I learned that TrueSpace supports multiple material formats, and you need to use the material type that's correct for your rendering needs. If it's a live interactive scene then use DX9, if you use the VRay renderer then use VRay materials, etc..


Can we create a TrueSpace Master Material that has an easy means of creating textures, and let TrueSpace handle all the rest?


If I'm in Workspace then TS can automatically feed the DX9 render engine the supported instructions from the TS material.


If I choose to render using VRay, then TS feeds VRay the instructions from the material that it supports.


Etc..


Then I dont need to create a scene using one material and be stuck only being able to say, render out of VRay. Then I can make my whole scene in Workspace using DX9 and it will still render using VRay or LW. And I can still see all the textures properly if I go to Model or Workspace equally.


This also acts as a material 'interface'. Also as you add in other rendering engines to TS, I dont need to learn a new way to make yet another type of material. You just add more options to the same TS master material editor and spare me from all the confusion.


I just want to make one good way to do things rather than multiple.


A similar concept to this is editing video. Prior to applications like After Effects, video editing was potentially a daunting task. You had to set up your video projects based on the specs of the footage you wanted to use. Once you set up projects you typically couldn't change the project specs after that. You also needed to often convert video from one format to another or the video would be garbled by the editor, or be less-than-ideal in some way.


Enter: After Effects. AE was one of the first applications to finally handle all the specifications internally. You could use video sources that are any codec, any FPS, fielded or progressive, any color depth, any resolution, any pixel aspect ratio, and it would render the video in the best possible quality.


AE removed the whole 'project preparation' (read: BORING AND DIFFICULT!) part. It lets me spend more time creating and less time fishing through technical, tedious and unnecessary detail.


I wish TS would take some steps to return back to being the "easier" way to model. It's easy to make a complex program complex to use. It's excessively difficult to make a complex program easy to use.

Post by TomG // Jun 15, 2007, 11:00am

TomG
Total Posts: 3397
While it sounds nice in principle, it is just not possible :(


Sometimes there just is no equivalent in the other render engine. This would mean that your "one material fits all" would have to avoid any special features (eg soft reflections in V-Ray, Subsurface Scattering in V-Ray, real-time tricks in DX9, and so on).


The end result would be a shader system that took no advantage of the special features of each render engine. After all, if all render engines were created equally, then there would be only one render engine :)


In order to fully exploit each render engine, which is to say in order to actually get the benefits uniquely offered by that render engine, you need to have unique shaders.



Now one editing system would be nice, though you would still have to remain aware of what was a V-Ray shader and what was a DX9 shader - that is just unavoiadable as noted.


The end result of making it one material fits all you can already have really, that is, just use the Phong material and nothing else. Here tS does exactly what you suggest and converts it to each shader, since it is "standard stuff" like diffuse and specularity.


The problem is its the non-standard stuff that gives each render engine its power, and then it is true that some things just dont translate :(


HTH!

Tom

Post by om1nous // Jun 18, 2007, 3:57am

om1nous
Total Posts: 0
Sorry, I wasn't very clear.

I am a programmer. Therefore as any programmer, I work with many objects. To make my work far more usable to a broad spectrum of people, we have to create what's called an 'interface'. An interface is something that you create so people have an easy, (fairly) unchanging, consistent, dependable means of using my code, without having to know how the code works.

The usefulness of an interface in programming is that if I vastly change my code, or add features or improvements, the 'interface' itself stays relatively the same. Sometimes it is expanded on as features are added, but largely it envelopes all of the code I write into one simple to use (hopefully) interface.

The concept is not that you would have on trueSpace master materialy that only only allows you to use features found in all rendering engines. Because as you said, you would be highly limited to that which all engines support, such as phong (which I have used for a decade). The idea is that this master material would support all features of all engines, but have a single, consistent interface.

Yes, you will still need to be aware of which features are supported on which engines. But a large amount of the same, unchanging 3d concepts (specularity, alpha maps, et al) can be achieved in all of the rendering engines, but have (confusing) different implementation requirements, even though the end result is similar.

Why allow this unnecessary complexity that only ends up adding time to building a scene? This is something Caligari can make significantly easier by creating a master material that real-time converts your material settings to their proper equivalents in each engine. If a feature is missing from an engine, it simply does not perform that effect on the render.

Again, it does not solve the requirement that an artist will need to know if the material can be performed in any specific engine. As much as I'd like that problem wiped out, it's very easy to indicate which features are supported in any specific engine. Everyone, as they already are, will get used to which features are supported where. However it will make the process of applying materials easier and more consistent if the same master material 'interface' is used to apply materials.

We'll never need to re-learn material application if a new render engine is supported. We will never need to re-texture a whole scene to support the engine either, as trueSpace would map over its own master material automatically. These two things should save substantial time.

As a long-time computer enthusiast, I've seen several technologies grow from their infantile inception into current maturity. The best ideas nearly always win, and rendering engines will eventually grow very similar to one another. At that point they will support everything fairly equally, only their implementation will become more and more complex. Down the road, this master material panel would pay off even more as Caligari simplifies the process of multiple render engine support with a single, consistent master material application panel.

Post by TomG // Jun 18, 2007, 6:01am

TomG
Total Posts: 3397
Hmm well we have this to some extent already. However a "master material" is not the answer, just a consistent interface is what is required :)


What is needed is that if you are editing Diffuse, it looks the same whether you are editing Diffuse for your DX9, Lightworks or V-Ray shader. Ie the interface is the same for that parameter. However, each material would have its own unique list of parameters - eg "Diffuse, Specular" "Diffuse, Specular, Reflection" etc.


That already exists to some extent. The missing aspects right now are the ability to effectively edit Lightworks shaders in the workspace, and DirectX9 shaders primarily requiring editing in the LE rather than in the ME.


Note on the "automatic translation" part, that paining an object with the V-Ray Caligari Phong will render under Lightworks with the "translated settings" for that shader, so that is already going on there at that level. Some shaders just aren't the same though - a Subsurface Scattering shader for V-Ray has no equivalent in Lightworks.


So sure we can grab the Diffuse and Specular setting since they show up in just about any shader - but what shadere should Lightworks use? Phong? Caligari Phong? Metal? Glass? In other words we need to pick a shader, any choice would have the main element of the Subsurface Scattering shader missing and which may not be the shader the user would want to use, so at some point the translation does break down. The best solution there remains the same - choose the shader based on your render engine. If you are rendering in Lightworks, simply do not use Subsurface Scattering shaders, as they are not supported in Lightworks and there is no equivalent :)


Shaders exist as separate entities for two reasons - one is that the underlying code may be different (eg my TG Glass shader works out how to add reflection and transmission into the shader in a way that is a little different from most). So you have a reflection value, but the underlying code is different. This means you still need to pick that shader though, so that you get access to that particular way of doing things. Also you can simply remove some code from the shader, resulting in greater efficiency - while you can turn off the calculations for transmission with a quick check "is transmission = 0" you are still doing one extra if statement to determine that - repeat that 200000 times for one render, and you have quite a savings by simply taking out the transmisson code altogether for a particular shader.


Next, some people find it inefficient to have "one interface with all parameters" - if I know my material is a carpet, then I know it will never have reflection, transmission, and many other parameters. It is nice to be able to control that material without having to see a list of parameters that do not and will never apply for the object I am working with.


None of that means there can't be consistency in the way things are presented of course, but it does mean that one "master material" is not a "one perfect solution" however.


You'll find this is true in other rendering apps too - every engine has its own shader interface with its own shader settings. The render engines are added as plugins, and the shaders show up in their own editing system, to allow the use of features not in the other engines. So the issue is by no means unique to ts.


We will of course keep moving to streamline everything in the best way possible, and further improvements on the ME are definitely on the cards! That is what is important, not whether it is solved via "one master material" or not, but that the best possible solutions for the widest range of users and uses is found.


However the understanding of shaders and what engine they belong too will still be important and still be something the user has to understand and keep in mind, no matter what we do to the the interface (ie Subsurface Scattering shaders will still not work under Lightworks no matter what).


HTH!

Tom

Post by om1nous // Jun 18, 2007, 7:12am

om1nous
Total Posts: 0
I understand completely why you created the panel how you did. I'm glad you're also planning on updating the ME and am curious how you will do it. I am also aware that TS is already trying to real-time render all the materials it possibly can, even if materials are used that are not designed for the real-time renderer. This is why I'd like to see most of what is already going on, wrapped up in a cleaner material application interface.

Just stated again to make sure I'm being clear, a unified material application process is what I'm seeking here. And this is very possible. How you do it is of the question.

Many other interfaces have advanced options that are not immediately visible to the eye. A material editor that has all the 'basics' of material application that are supported by all renderers (which are quite a few) would be a nice start. You can visually add in extra advanced panels for each part of the material (normal mapping, yada) with various render-specific options available. If I click on the DX9 button in the normal mapping properties, I would simply get all the DX9-specific advanced attributes for normal mapping. This does two things. First, I can set the universal properties that all render engines support using the basic panel in one broad stroke. Second, if I need DX9-only functionality, by clearly showing a DX9 button, I know if I open the DX9 panel, it obviously is for normal map settings specific to DX9.

Simple things like that allow me to universally set up a material as well. If I set up the material using no DX9, VRay or LW settings, and stick to the basic 'master material' panel, I know that my material will work in all the renderers. There is a lot of intuition to doing things like that, while never sacrificing the power of advanced functionality in any of the renders.

IF it is possible to unify the material editor into a single panel is not the question. It is. How to do it is really the only question. There are obvious benefits to unifying it, but I haven't seen why there are any benefits to keeping it seperated.

Post by frootee // Jun 18, 2007, 7:30am

frootee
Total Posts: 2667
pic
Hi om1nous. I cannot find the post at this point, although I saw it a few minutes ago; but, the truespace SDK is under development. It sounds like you have some really good ideas which you would like to see implemented. One thing you Could do is, email TomG: thomas@caligari.com, as pointed out by Tom in the thread which I cannot find now (eyes roll):cool: to let him know you would be interested in being kept up to date on the SDK release. With the SDK, you could experiment with your own ideas for implementing this.


HTH


Frootee

Post by om1nous // Jun 18, 2007, 7:41am

om1nous
Total Posts: 0
Can't I just be a whiny user and point out a potential area of future improvement? ;)

If the SDK is written in something I'm familiar with, I just may take a crack at it, but I use after effects about 80% of the time. 3D hasn't penetrated my graphics design quite enough for this to be something I invest a great deal of time in.

Though I'm an enthusiast, so I figured I'd relay a suggestion based on something I feel could be investigated for future improvment.

If I do this myself with the great UI editing tools and some scripting, I would be glad to hand it out! It's not a difficult thing to build, just tedious as all the controls need to be mapped intelligently to different implementations with a great deal of accuracy.

Post by frootee // Jun 18, 2007, 9:30am

frootee
Total Posts: 2667
pic
Can't I just be a whiny user and point out a potential area of future improvement? ;)


No. :p



If the SDK is written in something I'm familiar with, I just may take a crack at it


The SDK, I have heard, will be written in Visual C++. You can use Visual Studio for development. Microsoft has VC Express 8 for FREE.



Though I'm an enthusiast, so I figured I'd relay a suggestion based on something I feel could be investigated for future improvment.


True, but why wait when you can do it yourself? Sounds like you have a pretty good handle on what you expect to see, plus you're already a coder!



If I do this myself with the great UI editing tools and some scripting, I would be glad to hand it out! It's not a difficult thing to build, just tedious as all the controls need to be mapped intelligently to different implementations with a great deal of accuracy.


The scripting documentation is already available if you want it; no need to wait for the SDK. Here's an old forum link:


http://forums1.caligari.com/truespace/showpost.php?p=2334&postcount=4


HTH!


Frootee

Post by om1nous // Jun 18, 2007, 10:14am

om1nous
Total Posts: 0
No. :p

But... do they really expect to give everyone who makes a suggestion the shrug off with "Ok sounds great, now do it yourself!"? That wouldn't be very useful..

The SDK, I have heard, will be written in Visual C++. You can use Visual Studio for development. Microsoft has VC Express 8 for FREE.

Already have it installed, planned on toying with it but I stick to Java/ASP/PHP/SQL/expressions/lingo/JS/AS/etc.. Did ASM and C about 10 years ago but there are no objects in C so only the basics will apply. The knowledge transfers over only so well.

True, but why wait when you can do it yourself? Sounds like you have a pretty good handle on what you expect to see, plus you're already a coder!

I'd need to learn VC++, and THEN the SDK, and then do this. Not saying I won't dabble in enough VC++ to get the job done, but it'd be a stretch just to materialize what is otherwise a feature request for consideration on an application that involves less than 1% of my work time ;)

Thanks for the link though, I'll have a look-see when I get further acclimated with the interface and become less of a noob to begin with ;). Doesn't help yet to read about methods and parameters of objects and tools I can use when I don't even know the tools exist or where they are to begin with ;).

Often I like to have my development tested by people who've never used my apps before to get good, raw feedback. When you develop something, you see it in a different way. You don't notice small quirky nature, because you're already used to it. That's when I like to make any feature requests I can think of, right when I start a new version or new application. After I get used to the interface again and figure everything out, I'll seldom have any feature requests at all.. It'll be all business..

Post by frootee // Jun 18, 2007, 10:23am

frootee
Total Posts: 2667
pic
But... do they really expect to give everyone who makes a suggestion the shrug off with "Ok sounds great, now do it yourself!"? That wouldn't be very useful....


No. I'm just giving you a <friendly> hard time about being a whiny user. That's all. :D




Often I like to have my development tested by people who've never used my apps before to get good, raw feedback. When you develop something, you see it in a different way. You don't notice small quirky nature, because you're already used to it. That's when I like to make any feature requests I can think of, right when I start a new version or new application. After I get used to the interface again and figure everything out, I'll seldom have any feature requests at all.. It'll be all business..


I know what you mean. I am a software engineer as well. ;)


Have a good one,


Frootee

Post by om1nous // Jun 18, 2007, 10:59am

om1nous
Total Posts: 0
In all seriousness, if I end up using TS a lot more than I think I'm going to (you never know), I just may have to do this ;). I'd like to use the power of the DX9 view for speed and proofing yet not create unrenderable objects.


We'll see :cool:
Awportals.com is a privately held community resource website dedicated to Active Worlds.
Copyright (c) Mark Randall 2006 - 2024. All Rights Reserved.
Awportals.com   ·   ProLibraries Live   ·   Twitter   ·   LinkedIn