The non official Messiah 2.4 BUG tracker

[Taron333]

Not sure if this is a bug or a request:
when you make a preview, the camera aperture is ignored. I know there are codec determined proportion issues for the avis - but could we have at least the greyed in aperture mask in the preview?

David

Hmmm…that’s interesting. I would see how the frame format could be restricted, but the camera’s zoom and/or aperture should at least be covered. I like the idea of an optional mask! Good call!

Thanx!

[Taron333]

When using a procedural as a ‘tool’ mapping type for a texture - i.e as a simple reference object - it will not recognise any motion changes on the object the texture is applied to from its loaded-in position / rotation ( this REALLY tested my patience last night :banghead: )

I’ve attached an mpj showing the problem. Use these steps to replicate it :

Go to frame 97 and render. Remember where the black box is shown on the road surface

Now rotate the Road object 180 on heading and move it -4 on z ( doesnt matter whether you do this in animate or setup mode, the result’s the same ) Now render again. It’s still in the same position, nowhere near where the actual procedural object is :hmm:

Was that supposed to work? Are you sure about the whole tool-mapping idea? It doesn’t sound exactly right to me, but I saw a mapping section in connection with the procedurals, that’s true. I even saw mappings for all the types, now that you mention that. Hmmm…we are currently thinking about tossing the procedural objects until further notice, but the mapping thing…hmmm… Besides, I need to make a TextureDefrom tutorial, too, because this really allows wicked custom mapping of any texture and works under guaranty with no odd dependency to previously mysterious developments.
In the meantime our clean-up continues and your post now makes me think about looking at the procedurals one more time before we continue with our idea of tossing them. In some odd way, we could do the polygon object replacement concept for rendering them, but retain the mapping tool they may represent. Which then would also definitely make us ensure that it acts correctly as such.

Just one tiny little hint for you what you can do if you want to move around a texture with a reference object. Just use Texturedeform. Hook textureDeform in between your shader and your material, or where ever you had the shader connected to. Just watch out that you really use the same kind of output that you’ve chosen for an input (color (in) -> color (out), value (in) -> value (out)). I’ve made them separate for a good reason. You can modify multiple textures with a single textureDeform node. Like a color and a bump for example and so forth…it’s rather convenient I found.

I hope that was at least a little bit of a help for you…sorry about the funny and strange corner you maneuvered yourself into there…we’ll take care of it one way or another, no worries. :wip:

[Taron333]

You are right - now I remember.

For rigs I don’t think they are really “important” - don’t know, never used them.

The mapping is a different topic. I personally find it absolutely weird to use them for mapping or weighting, since they are “visible objects”. From day one I thought this to be the wrong way to go.

Yeah, you know, I was kinda surprised to read that anyone even tried that. I had no idea that was the idea…I know that’s funny, but I believe that this was one of them weired concepts that we weren’t fully aware of. It might have been some kind of general idea for a use of tools within shading or so. It might be interesting, but then, too, what for really…wacky experiments mostly, I would figure. Using the curves for mapping is a lot more interesting, and I do remember that that has worked…but I was never too fond of curves anyway, because they are rather tricky to handle at times (rotational things)…but that’s just me.

• For mapping, a visual cue with a grid in openGL (similar to Cinema 4D for instance) would be way more helpful. I would love to see it implemented in a way, that as soon as a texture map node is active, it’s accompanying “texture grid” shows up in the world view (as a plane, a cylinder or a sphere etc.). It should show rotation/scaling and position - direct manipulation would be killer but I could live without it. In Cinema 4D, mapping was so easy since you were able to see your mapping in space and manipulate it like any other object.
  The procedural objects try to do the same, but are somehow weird and don’t feel right to me - they live in a different “space” from rendering.
  I don’t think anyone likes them?

Yup, like it. It’s the whole visualisation issue that we’re having ahead of us. It’s far more than just this one, but it would go straight to the list of things to remember! While it’s exactly this kind of thing that makes me worry about eventual impatience again. We’re crunching our way through everything and some things may not happen as early as others. As long as the whole user crew gets to exploit the things we are doing for them, it’ll all progress just nicely. I just don’t want people to start going: “Oh yeah, I’ve read about that request, why arn’t they doing that, I guess they don’t do nothing…” hehe… you know, that’s what I’m worried about. I think it’s time to just hold back a little bit or pile up a new secret stash…or just send some of those ideas to me privately. Oddly enough, you’re wishes were so far not just next to 100% like mine, but also easily 80% of what we’ve currently been dealing with. I leave out 20%, because most new visual feedback elements are coming a little later and will have such a great impact on the whole package, despite the fact that Fori was already hooking up some visual helpers for the particle emitters of course…

• For weighting I find metaeffectors okay, but procedurals weird again. In the end - give me good weightmap support for rigging and rendering and I will be all fine.
  Since this feature is needed in messiah anyway to make it a considered tool in games or many other pipelines, it would be a AAA priority for me.
  And don’t get me wrong - I don’t talk about replacing the current “non-weights rigging” with making weightmaps mandatory for everything, but for certain riggs, all games and also rendering, per-point weightmaps are very useful or simply needed.

Just my half a dime

Cheers,

I recently had some troubles with the weightspot, but in very outlandish circumstances, yet, enough to trigger my desire to look into them a little deeper, too. However, yes, yes, yes and double yes, the weightmap support is a must that we partially had already. I thought we would have it fully in again…not sure…but however, there’s a slight potential, as far as i can tell, that we could in theory make some weight painting possible in the nearer future. We (as usual by now) were talking about that already, too, of course, but that’s already a few months back and was in connection with a different development we were starting with.

Useful is to me enough of an arguement to claim that it is needed, hahaha! But I actually mean that, too. If something is truely useful, it means that it has a genuine purpose and would be needed to help with a proper workflow. And workflow’s almost everything. You can always noodle yourself to death with wicked workarounds, but you don’t need any specific software to punish yourself like that. I like the idea a lot and I can totally understand how games actually need it (currently). In the future things will look differently, I can absolutely promiss you that, but it would still make the weighmaps useful. So…good point! Thanx AGAIN! :lightbulb

By the way, after people were talking about their confusion about the “SpeedHazer” and it’s ability to deal with solid volume, I’ve decided to outsource a portion of it and call it “Voxelini”, because it does such magical things…hihihi…SpeedHazer still retains the potential and all the same features as it has them now, but the specialized Voxelini will come with a few more specific features.

[MoodyB]

Was that supposed to work? Are you sure about the whole tool-mapping idea? It doesn’t sound exactly right to me, but I saw a mapping section in connection with the procedurals, that’s true. I even saw mappings for all the types, now that you mention that.

I hope it was supposed to work, as there was no other obvious way of using a reference object to animate a textures position. Anyway I managed to get it to work using weightspot and it’ll do for now.

Just one tiny little hint for you what you can do if you want to move around a texture with a reference object. Just use Texturedeform. Hook textureDeform in between your shader and your material, or where ever you had the shader connected to. Just watch out that you really use the same kind of output that you’ve chosen for an input (color (in) -> color (out), value (in) -> value (out)). I’ve made them separate for a good reason. You can modify multiple textures with a single textureDeform node. Like a color and a bump for example and so forth…it’s rather convenient I found.

I hope that was at least a little bit of a help for you…sorry about the funny and strange corner you maneuvered yourself into there…we’ll take care of it one way or another, no worries. :wip:

Thanks Taron this should help quite a bit.

[rush123]

" By the way, after people were talking about their confusion about the “SpeedHazer” and it’s ability to deal with solid volume, I’ve decided to outsource a portion of it and call it “Voxelini”, because it does such magical things…hihihi…SpeedHazer still retains the potential and all the same features as it has them now, but the specialized Voxelini will come with a few more specific features."

Taron,
As someone who has been wrestling with ‘Speed Hazer’ and struggling to get solid volumes from it, I can at least attribute some of my problems to using the procedural shapes, which made testing quick but inconsistent and floored (my bad!). I’ve being trying unsuccessfully to produce a shape out of haze. But this might be possible in ‘Voxelini’ is this the case?

Cheers
R

[MoodyB]

This might be a gfx card driver issue rather than a Studio bug, but right clicking on the icons for diffuse / specular in the lights block of a surface does disable the diff / spec, but it doesn’t change the icon to the ’ ghosted ’ version.

[stooch]

Some hugely annoying bugs, alot of them are old news and are long overdue for a fix:

-If im working on setup mode, and have a null selected, i cant select a bone in perspective view until i click on another bone in the item list.

-why is it that when i move my mouse over items in animate mode, they highlight allowing for precise selection, but in setup mode they dont, often resulting in wrong items being selected. The fact that then i cant re select an adjacent item because of the widget makes things even worse!

-cant click on bones under the widget. speaking about the widget, how about adding a handle for scale, in general id love to see very clear handles for move, rotate and scale. the middle handle should always allow freemove/rotate (think silo). Currently the widget is very awkward to operate on, im also not seeing the new fangled highlight features when moving my mouse over the various widget elements.

-when i have my widget enabled, its elements should always hve the top priority, currently if i have an adjacent armature near or under the widget, the armature takes precedent. I feel that the widget elements should have the precedent at all times! (im not talking about the shaded circle either, that should be transparent as far as selection is concerned)

-i can replicate the stupid list scrolling bug that forces you to scroll to the bottom of the list. Try replacing an item with a layered object, when it pops up the prompt to select a layer, it will always forcibly scroll you to the bottom of the list the first time you click on it.

-selecting items in the lists is also a pain in the ass because they are unsorted alphabetically. In fact, the whole selection scheme should be rethought, instead of dragging through hundreds of items i would love to have a search string input and automatically have it highlight the closest matching item name string as you type it in. Huge time saver here.

-when i type in a space in an item name, it automatically inserts an underscore. the expression editor however lacks this feature, can i ask what the reasoning behind this is? i mean, chances are if im typing it an item name, i would want it to match an existing item name, which will always have an underscore instead of a space.

-if you scale down the item list, the tabs on the bottom get overlapped. What does “blocks autofit” do? I have yet to see this feature in action.

-cant search and replace in expressions.

-reloading the same scene still causes a crash.

-sbd collision detection is broken.

[WesComan]

Some hugely annoying bugs, alot of them are old news and are long overdue for a fix:

-If im working on setup mode, and have a null selected, i cant select a bone in perspective view until i click on another bone in the item list.

Strange, I don’t have that problem.

-why is it that when i move my mouse over items in animate mode, they highlight allowing for precise selection, but in setup mode they dont, often resulting in wrong items being selected. The fact that then i cant re select an adjacent item because of the widget makes things even worse!

Have you turned on Animate Immediate In All Modes (right click Animate tab)? To select items within the edit sphere you can use the old method of middle click.

-cant click on bones under the widget. speaking about the widget, how about adding a handle for scale, in general id love to see very clear handles for move, rotate and scale. the middle handle should always allow freemove/rotate (think silo). Currently the widget is very awkward to operate on, im also not seeing the new fangled highlight features when moving my mouse over the various widget elements.

Selecting bones as above…middle click. The handles for scale are turned off by default ('cos they aren’t animated very often), all of the channels can be hidden/unhidden by right clicking the little ‘key’ circle on the motion block (but to be fair, unhiding the scale handles doesn’t help much, it especially conflicts with Animate Immediate). Highlighting on teh edit sphere is turned on in Edit->KeyFrame Editing->Edit Sphere

-selecting items in the lists is also a pain in the ass because they are unsorted alphabetically. In fact, the whole selection scheme should be rethought, instead of dragging through hundreds of items i would love to have a search string input and automatically have it highlight the closest matching item name string as you type it in. Huge time saver here.

Move the cursor over the list and type the first letter of the item you want to find. If there are multiples it will step through each one alphabetically.

Hope these little tips help

[stooch]

ok that does help tremendously. i guess the biggest bug here is the lack of documentation,
and why the F are the options for the edit sphere in the EDIT block??? what about customize? not very intuitive.

[kvernon]

I’ve been having an issue with distant lights and raytracing. Can anyone confirm this?

It seems that it doesn’t want to cast a shadow or pass light when going through glass. Example… If there is a room with a window, the light doesn’t pass through the window. I have to hide the window object for light to pass through the area.

Sincerely,

Kelly

[MoodyB]

I’ll check this for you in a bit

Kind of related I suppose, I have had M:S go funky in the scene I’m working on when I have 10 raytraced lights ( distant and point ) active and casting shadows. When rendering, the memory useage goes through the roof - climbs from the scene’s normal 1.3gig to over 2gig in about 10 to 15secs - then it either crashes with the usual Windows error box or disappears from my desktop. I’ll need to try and recreate the crash in a smaller standalone scene.

I’ve also had Studio crashing when I try to save after clearing multiple layered objects ( 10+ ) from the same scene, so it could be something funky in the way I have it set up that’s causing the problems :hmm:

[AAAron]

I’ve been having an issue with distant lights and raytracing. Can anyone confirm this?

It seems that it doesn’t want to cast a shadow or pass light when going through glass. Example… If there is a room with a window, the light doesn’t pass through the window. I have to hide the window object for light to pass through the area.

Sincerely,

Kelly

Transmissive shadows turned on for the window object in the surface tab?

[kvernon]

AAAron,

Good idea. I’ll double check when I can get back to the project to see if the windows are set to transmissive shadows. I’ll report back later on that.

UPDATE:: I checked it out, and AAAron, you were right. Thank you very much!

Warmly,

Kelly

[ThomasHelzle]

Taron, thank you very much for the feedback.

I see your problems and concerns, but it makes all the difference for me to see you think out loud about them.
You have quite a lot on your plate to clean up and it will not be possible to do that to everybody’s liking in a short time.
Yes, there will be some complaints but they have been there all the time anyway.
IMO, you have nothing to loose, but a lot to win.
I personally enjoy reading about your thoughts and internal discussions and feel a lot more insured that messiah may become the piece of software it always earned to be.
Not tomorrow, maybe not this year, but I’m in no hurry as long as it is done right and I can see and understand what’s going on.

The old way didn’t work, that’s for sure.

Alles Gute beim Ausmisten der Ställe des Augias

Best Regards,

[stooch]

Shnell!

lol thats the only word i know in german.

[Geco]

Shnell!

lol thats the only word i know in german.

Schnell!
Alles Gute beim Ausmisten der Ställe des Augias means: best wishes with the clearing of this very dirt place

[ThomasHelzle]

Well, actually it is one of the adventures from the hercules saga, when the hero has to clean out those stables of the ancient king Augias…

Cheers, :wavey:

[Geco]

so i was not totally wrong

back to the bugs:
can someone take a look at this?

Double Armatures | Geco | CGSociety Forums

thanks

[THUR]

anyone felt like the rotation of a object,bone or null is acting strange when changing direction? ( since editsphere extra ) Weird and verry frustrating when animating a entire day! Forced to do some of the rotations in the graphic editor by grabbing the keys on the curve helps … but a silly and timeconsuming workaround! concidering I worked with messiah way before the stand alone version arrived and never before found such a frustrating bug!

help!

THUR

[ISeeTheStars]

hey

maybe a bug, maybe not
but image sequence aplied as image in spotlight (projected image?) doesnt show a sequence … only first frame

Cya