New versions 2.4b are up!

#121

I’ve already written something like that…hmmm…hmmm…I could go dig, but it’s really an easy one to write…we’ll see…but great! =)
I, however, do like using actual bones to design the stress directions exactly with the animation…it’s just as easy and give great control AND ultimatively renders even faster, of course.
But I like it. Not as much as the motionvector layer, though, hahaha, that one’s just beautiful! Man, I’m almost angry that I wasn’t thinking of that one…argh…I keep wanting to remember I did…but no…just so damn similar in principle. Fantastic! :bounce:

#122

Hmmm… I’d need more insight into this. I see the bones as better for under-skin sliding areas such as neck tendons and shoulder blades, but a mask of tension areas would be simpler for locating the on-skin type tensions (ie wrinkles) right?

Haha! Its not an either/or - me wants 'em BOTH! :stuck_out_tongue:

#123

Hey, isn’t that nice: Newtek made an example video for us about how this could be impemented :wink:
ftp://ftp.newtek.com/pub/LightWave/LW9/StressMaps.mov

Just kidding,

#124

Hey, isn’t that nice: Newtek made an example video for us about how this could be impemented :wink:
ftp://ftp.newtek.com/pub/LightWave/LW9/StressMaps.mov

Just kidding,

You forgot to mention you have to go through 8 submenus to do this, and part of it has to be done in layout, then you switch over to…hey wait a minute wasn’t this a plugin? :banghead:

#125

Hey Nichod, the joke was lost on you I fear. :wink:
In messiah, it would simply be a node that you could use to mask areas out…
I don’t know why they didn’t put it into the new LW node editor - that looks not too bad IMO.

There even is a function in the messiah SDK to generate such stress maps, but it didn’t work correctly when I last looked into it.

BTW. Taron, would you have the time to comment on this idea of mine?:

Also, I have talked with Stooch about his need for a Real Flow importer. I see two options: either pmG builds one, or the SDK finally gets options for creating meshes, say Importers, custom object loaders, procedural meshes…
I personally prefer the second option, since it finally would open up messiah for custom pipelines.
But I don’t know how far away the inclusion of this in the SDK may be?

And another one: Taron, I was asked about the Ambient Occlusion shader. Since this is a very important concept, I think it would be cool to have it included in the core. And maybe it is possible to make it more efficient with access to the internal ray functions?

Ok, over and out :wink:

Cheers

#126

I feel honored. :slight_smile:
If you could make it so that it at least has a switch to conform to the settings for Reelsmart SmoothKit ( Red Channel: X [0,1] - Green Channel: Y [0,1] - Blue Channel: Intensity [0,1]) that would be nice, because I am already using a nice shake macro that uses this method (http://highend3d.com/shake/downloads/macros/filters_effects/2965.html).

Hmm, did anyone say Curved Motion Vectors? :twisted:
That would be nice too, however I have no idea how to use that in compositing at first glance. If someone has an interesting link, I am all ears.

#127

Hahahaha…man…I should stop writing like I’m speaking! But anyway, the motion vector curves would be an internal treatment to get “perfect” mostionblur without having to compute the otherwise necessary animation frames. But it’s all just ideas at this point, so don’t take this as a promiss of any kind, before we get our heads cut off for not having it done by the time our next release goes out! :surprised :smiley:

BUT there are a few great things that will make it into the mix sooner than later. Yet, it’s all about…well, you know what it’s all about. Getting it right first, then making it go up! :bounce: :wip: (these two smilies are ment to show the procedure…not express the emotional aspect, hihi! So not “emoticons”, but “demoticons”) :cool:

#128

Ooopsy, more to answer, sorry, I missed this one! Alright, let’s see…

Ah, the shaderflow individual outputs concept…hmm…in the beginning, this was what I was expecting, but I’ve grown used to the way it is implemented now, which is really not to troublesome. BUT, (wait, wait, wait) we have already been talking about what will be called “custom buffers”, which would allow the creation of output layers for compositing based on what it is you’d like to output exactly. This may end up being very much like you’re describing.
A few days ago we’ve also been talking about locking the material node to the right side of the screen, so you really have a docked bar with all the inputs for the final node always at a known location and can arrange it actually more conveniently. I was asking for that for a long time already, just to optimize the workflow, so we’re looking into that right now, too.

Again, please, everyone, don’t drop it all on us at the same time, though. It so quickly leads to impatience and that would start a bad cycle again. I’m loving the feedback you all are giving right now and really get excited myself to have us implement pretty much all of it, but we really still need to take care of everything else and than each new thing also requires some time to do. It’s all actual work and some of it actually hard work, so let us do that stuff and hang in there and do us the really kick-booty favor to not just check out what we’ve got going currently, but to simply do something cool with it! That would be the number one ticket for us to accell right now! With our momentum it then is becoming even more likely that all these new ideas get done within a time that wouldn’t test your patience as much! :bounce:

Oh…there was something else from you, Thomas…uhmm…AHHHH, the ambient OCCLUSION, yes, yes, yesssa, that was one I’ve been bugging for, too…it’s about the internal ability to switch between raytrace and raycast for radiosity ray emitting, plus the API availability of that choice! This would allow a very simple way of implementing ambient occlusion. Oddly enough, on a global level it has been implemented for a long time, if you simply choose the right type of radiosity in the render settings tab (environment only), but I’m sure that not what you’ve ment, I’m just mentioning it.
Thanx, that was a good reminder! :thumbsup:

Sorry that I missed this posts a bit…but yeah…very cool!

#129

I hope you don’t mind me posting this then ? As much as I love to see all the rendering engine enhancements / ideas that have been talked about over the past few weeks, and the thought of being able to play with them in M : S one day is :bounce: , a lot of existing users would probably prefer that adding COLLADA support into Messiah / Studio was given some kind of priority :

I apologise in advance if this annoys yourself or anyone at pmG, as I guess you’ve probably seen the thread above and didn’t choose to reply in it, but I thought I’d bring it back to people’s attention before it slips into the forums archive to be lost as it seems like quite an oppertunity to fill a gaping hole left by Motion Builder…

#130

Also real 3D armature shapes :slight_smile: and not have them scale relative to screen. it becomes nearly impossible to select body parts when you zoom out and they all overlap each other. btw, to me armatures are 60% of what makes messiah great for CA. Lets not forget the old search and replace in script editor too. thats a long time annoyance but oh so useful.

also. im beta testing lw9 and i wont go into detail here because of NDA but simply looking a the publically available feature list, i can see potential integration issues with messiah. especially with the ngon support and weighted edges. Not sure if messiah already supports this but to me this is going to be crucial.

#131

Yoh, well, that’s been one of my expectations for them right off the bet, back then. The bigger question is far more: Wouldn’t it be just as easy to use expressions as they are for linking 3d stand-in object to the bones and such, just put them into a group and turn them on and off as you feel like using them…hmmm… armatures require also some setting up, although certainly a little more convenient…hmmm…alright, now, don’t rip off my head, I know exactly what you mean, but still. I think 3d armature helpers really suggest even more some means of automatic rigging and that is a big topic again anyway. So, well, we shall see. Lot’s of things to take care of first, but it’s on the list!
As for the overlapping, yes, don’t forget that armatures are helpers that you get to design yourself. depending on what it is that you’re doing, you could design them in a way that this would not become a problem…I think…while scaling…hmmm…maybe scaling ain’t much of an issue either, not sure…we’ll have to talk about this internally again. It’s absolutely amazing to me how many things are currently not much of a problem…so maybe that’ll turn out just the same!? No promisses right now or right away, but yes, it’s in our heads now, too!

I don’t think I told you that on this thread, but I currently see that we’re getting overwhelmed with great feedback, reports, ideas and requests, but it’s growing to be impossible to keep up with all of it in a timely fashion. So right now I would ask from all of you to go ahead and do something with the stuff we were already putting into it, even if it’s just some neat little experiments. Again, I’d love to see more renders, or even some little rendered animations, displacement, particle stuff, anything… …that would be the perfect thing you could do right now. We’re going through all the current feedback and will be busy with them for a moment! Again, usually I would have said, keep’em coming, but I’m growing to be afraid that it could cause you to become impatient, if you drop it all on us right now. Great stuff nontheless! SO, THANK YOU ALL, and we’re doing everything to reward you for your fantastic colaboration! Brilliant and very, very uplifting! :bounce: :thumbsup:

:wip: (commence working on next release!) :buttrock:

#132

haha, ok i have a project im making specifically for messiah. so stay tuned for some screenshots. lets just say its a bit more complex then some balls in a square room…

#133

Hey Taron. I think this is just the result of a clogged communication suddenly run free. :thumbsup:
I’m sure everybody would prefer the next update taking some days longer instead of the com link dead once more. I’m sure a good medium level can be reached after a while.

Just ride the wave and every now and then clear the air if something goes out of whack but don’t retreat to deadly silence if possible. Clogging always leads to further, bigger damage.

As far as Ambient Occlusion goes: I have it working already, but I wonder if an speedwise optimised routine could be used (or made available to the SDK). If you need further detail, I will be happy to provide it.

And one last request for the SDK: Can we have a similar function to fxShaderConnectedInputs for outputs? FX_OUTPUT_REQUEST doesn’t work for that because of the internal buffering, so knowing which outputs are connected to something would help a lot more when optimising speed in certain situations.

Thank you

#134

My 2 cents:
collect the input on a priority list. For example, nichod’s node-based in-program compositing is a possibility - say: priority C. If it all, then down the road. Everyone can contribute opinions (pros/cons) and it may refelect approaches to things being implemented now.

Priority B would be additions like Thomas’ buffer nodes (correct me if I’m wrong) or COLLADA. Mid-term things that would be great enhancements and even USPs, but need to be discussed further and slotted for development. And users will feel more strongly about some things than others (I’d never heard of Collada). Take it as a compliment that this sort of discussion and dreaming has been provoked! It’s great to participate in musings about where messiah might be headed and what may be possible - but there’s no pressure to implement immediately. Just a road map of ideas and a testimony to the community interest in your software.

Priority A would be more pressing things like bugs on the one hand, and Marek’s edit sphere calculation requests. And - ahem - ShiftToggling channel activation . :wink:
I’d spread-sheet them and post it on the wall. Nothing more motivating than being able to check off an A-level request or bug. I’m elated to see how many annoying little things have been adressed in such a short time! Things that have been gnawing at the program for years!

Keep up the communication and keep an eye on the priorities… messiah has always been grass-roots. Thanks to your efforts this last month it’s getting back to that.

#135

I would vote for a site (that might be only available to customers) where we have a bugtracker available. That way we can see if a bug is already known and what priority it is. And stuff doesn’t get buried in deep forum threads. Hard for anyone (especially the developers) to find again and even harder to see if you didn’t read the forum in a week and the thread is already a few pages on the back.

Oh and of course instead of having thousands of threads that go like “I want this and that” we have a nice clean overview of feature requests and could vote for them instead. That way it would also get more clear what we, the customers and users want most. And not only who might be the loudest (and probably most nagging).

What do you think?

#136

I think: yep.

#137

I think: yep

This being one of those old requests too :wink:

Cheers, :bowdown:

#138

Sorry, but just stumbled upon another of those old super-buggers that I miss 100 times a day when trying to work in messiah:

  • A shortcut to fit the view the mouse is over to the scene. (“A” in XSI)
  • A shortcut to fit the view the mouse is over to the selected object. (“F” in XSI)

I also miss the option to directly navigate the camera like a perspective view and having the camera adjust accordingly - so much faster and way more intuitive than fiddling with the editsphere in camera view… :slight_smile:

Cheers,

#139

I would vote for a site (that might be only available to customers) where we have a bugtracker available. That way we can see if a bug is already known and what priority it is. And stuff doesn’t get buried in deep forum threads. Hard for anyone (especially the developers) to find again and even harder to see if you didn’t read the forum in a week and the thread is already a few pages on the back.

Oh and of course instead of having thousands of threads that go like “I want this and that” we have a nice clean overview of feature requests and could vote for them instead. That way it would also get more clear what we, the customers and users want most. And not only who might be the loudest (and probably most nagging).

What do you think?
I could set this up. Providing someone gave a website/space. Would be fairly simple to do, since not much “design” would be required. It could be a big advantage, because we could post up the feature requests there and provide our own priority, then pmg could sort it out quickly…rather than browsing the threads and writing it down on the nearest stickie note. Though I’d hope that even if we did this that people would still post and share ideas here. Thats the only negative I see about that.

#140

I could donate space.