CrazyDave - all messages by user

2016/2/26 16:46:20
360 degree video test The cube map is mapped through an equirectangular projection which is done per pixel on the CPU and is very slow, hence shocking rendering times. I hope to speed it up by doing it on GPU at some point.
2016/2/26 16:41:03
360 degree video test 6 cameras actually Doc Whom! Looks like the explosion effects are breaking it... I'll take a look when I get a chance but it could just be the way it goes.
2016/2/26 16:39:07
Movement in a small space The problem with this is that any movement must play a start-walking animation, then a bit of a walk animation and then a stop-walk animation in order to be smoothly animated. This necessarily carries the character a longer distance than may be desired. Further, the tuning circle is limited to avoid foot slippage.

I think back and forwards movement in a confined space is always going to be tough to direct. Perhaps walking in a circle would be easier but have the same dramatic effect... That wouldn't involve all the sop/start animations.
2015/8/14 15:07:41
What are teleports (as in:Fix Teleports message) The most accurate explanation I can give is this:

If a character is directed to move from point A to point B at time X (through locomotion or action). Then the user rewinds to time Y which is before time X (the character will scrub back to point A). Then the user records movement from point A to a new point C. The character will now teleport between point C and point A at time X.

This is done to maintain positioning of characters in cameras at the later time i.e. the early stuff doesn't mess with the later stuff.

The option to fix teleports will just make the path continuous i.e the character will move from A to C then to a new position that is defined by the animation in a continuous path with no breaks.
2015/3/3 10:46:08
March 2015 update bugs Hey Ziggy.


You might also notice that things are always the same in cameras and final output as in the main vieport... This wasn't always the case. Any problems remaining with this please report it.

"this release has made the DX9 version much worse"... I confess I mostly had DX11 on when I was fixing things up but it should be right on DX9 too.. In what way is DX9 broken? I'm checking it out now and shadows are in right places in main viewport, cams and final output and the "shadow base" slider works... I must be missing something... Please be specific!


Cheers, David

EDIT: I see you emailed Bob about the DX9 issue, he's forwarded it and I'll take a look.

ziggy72 wrote:
Breathing fixed? BREATHING FIXED!! Well, thanks, but there's no need to go about it... Big Grin

Seriously, thank you for sorting that. You have to give them an action to get them started, even just an idle, but it kicks in after a couple of seconds and they don't breathe again. Wonderful. Robots rejoice! See folks, you only have to request something repeatedly, on every single email you write, for 2 years, and then as if by magic... Big Grin

Mandy! I wondered what happened to the Football Special stuff, nice to get it bundled in, thanks - she's good, if lacking attachment slots. Gotta give the tie and headset to the other characters as well though, be a pity if only the Man character gets it.

Good to hear about the movement thing getting fixed - less 'why wont this work?!' posts to answer

The lighting issue I was having - this release has made the DX9 version much worse, and the DX11 version much better. The Shadow Base slider is a brilliant fix, thankyou, as it means you can tweak out the flashing and strobing as you go, which is what you need when you're in a hurry. The DX11 performance also seems to have been kicked back into life, and is more on par with DX9 again, so I I'll just switch to 11 and call it sorted Certainly all works at distance now, thanks again mcmillan-ra! Check out these trees now!!



I haven't had any texture issues on loading these sets. I don't have any particular trick to get Muvizu to remember them on imported objects, it's to do with the way I create them, I think. I import the object to check it works, takes shadows, textures, etc, then tweak it further in Sketchup or whatever, remove the collision, and reimport. I open both property boxes for the new and old imported objects, and drag the textures from the slots on the old object to the same slots on the new object (because it takes too long to go back into Explorer each time, or search down the list, and I can't always remember what texture goes where, so it saves time). For some obscure reason, Muvizu doesn't 'forget' the texture if an object is textured this way - that's my theory anyway

Muvizu HQ, you've made my year already, thank-you all. Toast

edited by CrazyDave on 03/03/2015
2013/4/23 13:26:46
So much potential, so many bugs ukBerty wrote:
The distance and shadow settings seem to look different. Is it just a case of adjusting each set as I convert over, or can something be done ?


There have been some minor modifications to the way shadows behave over long distances. It shouldn't affect most sets but if it does you will have to adjust them manually as an automatic conversion process would not have been possible to create, sorry.

Let me know if there's any problems associated with this as any changes should have been improvements rather than hindrances.
2013/4/23 10:07:07
So much potential, so many bugs ukBerty wrote:
Could you confirm whether this is in Muvizu-Play and what the switch is please.


It is indeed. Launch the app with "Muvizu.exe -forceSWAA".

D
2013/4/11 14:48:10
Muvizu:Play (V1.0) Feedback mcmillan-ra wrote:
urbanlamb wrote:

found another bug.. this render took me like 8 hours of work due to the timeline issues


Hi Urbanlamb,

Do you have a way of getting the dots on the floor like that? We've had this a few times and we thought we'd ironed out the instances of it - but obviously one has slipped through - or re-appeared. Are they still there if you reload the set - and if so, could you send it to us to look at?

Thanks


I've been trying to reproduce this today with no luck. I'm positive that the pink dots would not re-appear on a loaded set... and so the bug can be worked around by saving and re-loading. I would love it if someone could give me hint on how to get the bug to happen though!

Thanks, Dave
2012/12/12 12:00:38
Feedback Thread - v0.23b release (Nov. 2012) urbanlamb wrote:
Hi sooo..
the focus/depth of field seems to be a bit odd lol it kind of like focusing top half/bottom half instead of back/front hard to explain anyhow here is two screenies...one from the make video window and one me watching the clip you will see what i mean



I got this sorted, will be in the next release. It was a code issue with depth of field and transparency.

Screenshot of before/after in my dropbox...

https://www.dropbox.com/s/xhfo73935b4u4zj/DoF.jpg

Dave
2012/12/5 17:08:49
Feedback Thread - v0.23b release (Nov. 2012) ukBerty wrote:
Keep upright just introduces the "wobble about" or "refuse to go upright" issues. It's useful to set the upright position when the object is on the ground, but is best avoided otherwise.


Also, I haven't checked with many imported objects but it should generally be the case that if the object is created with it's origin at the bottom of the object and centred when looked at from above then it shouldn't wobble and should get upright ok (this has been improved recently). Maybe I'm being overly optimistic though :-)
2012/12/5 16:52:23
Feedback Thread - v0.23b release (Nov. 2012) I've put your suggestions about imported props into our internal database... I fear that the idea of having the defaults for imported props on an option panel would come under the category of overcomplicating/cluttering the interface which is intended to be as clean and simple as possible to do the job, but I'll try and start some kind of internal discussion.

I'm just going to add saving/loading of "only walk" and "only run" as a new feature as it's easily done, won't do any harm and I can see why it's annoying to have these properties changed when you load a set.


Dave
2012/12/5 15:27:58
Feedback Thread - v0.23b release (Nov. 2012) ukBerty wrote:
Yes the prepare/direct bug was an old one, but not saving with the set was new.

There's also an issue with remembering a character's "only walk/only run" status between saving/opening a set, which is also new. Will this be sorted with the same fix (it's not as important as the camera speed one).


Hi Berty,

I just checked the code and there's actually nothing there to save the "only walk" and "only run" values for a character with a set. I also checked on an old version (0.19b) and if you save and load a character these values are not retained.

I think this is correct though: to me they are more transient controls rather than values inherent to the character that should be saved... but I'd listen to any opposing opinions :-)

Dave
2012/12/5 13:33:16
Feedback Thread - v0.23b release (Nov. 2012) Yup, the values for the object and camera movement sliders were getting lost between prepare and direct modes (if you started direct from the menu) and also when loading sets. Fixed in next release.
2012/11/27 14:44:29
Feedback Thread - v0.23b release (Nov. 2012) urbanlamb wrote:
the focus/depth of field seems to be a bit odd lol it kind of like focusing top half/bottom half instead of back/front hard to explain anyhow here is two screenies...one from the make video window and one me watching the clip you will see what i mean

I've had a look at this. I can't get anything to look different between DX9 and DX11. It seems to me that the problem is that the depth test for the DoF blur effect is not "hitting" your trees.

I don't know exactly how these objects have been constructed but perhaps integrating some actual 3D geometry into the tree model rather than just alpha'd textures could fix it.

Perhaps I'm barking up the wrong tree however.

Dave
2012/11/23 12:11:28
Ready Break glow with Anti-Aliasing ukBerty wrote:
Dave, thanks - that workaround sounds perfect. I can always test render with HW AA and only switch to SW when producing the final AVI. Is there any way of getting this in the product somewhere so I don't have to exit ?



You could always turn AA off for your test renders and turn it back on (with forceSWAA activated) for your final AVI!

I'm still going to give this some thought though as I would like to find the best way to balance rendering times with AA accuracy.

D
2012/11/22 18:09:17
Ready Break glow with Anti-Aliasing Not really, adding a menu option would run the risk of cluttering up the interface with indecipherable technical options.

I'll look into other options in the mean time though.

Cheers, Dave
2012/11/22 11:57:36
Ready Break glow with Anti-Aliasing Berty, thanks for pointing this out.

I've had a look and can see it happening on my machine (also a GeForce GTX 460).

You're using hardware anti-aliasing, performed on the graphics card. This isn't really our code and the problem would be very hard to track down. The problem could potentially be with the nVidia drivers. I don't think this would ever be noticed while playing a computer game, but for creative output people are more discerning about wrongly coloured pixels...

To that end, in the next release (0.24b), if you launch Muvizu with the command line parameter "-forceSWAA" then it will use software anti-aliasing performed on the CPU instead. This will slow down your video rendering times (so I do not want to change it by default) but it will avoid these artifacts.

Also, if you are desperate to produce a particular video without this issue using the current version of Muvizu (0.23b)... and if you have access to a PC with either Windows XP or an older DirectX 9 graphics card installed... then your video will be rendered using software anti-aliasing without these wrong pixels.

Hope this helps,

Dave
2012/10/24 16:59:22
UE3shadercompileworker perri wrote:
yes. And it is in the folder. When I try to start it, just for fun, it says that it is not configured properly and a reinstall might help. It does not. Thanks and double thanks for your help.

perri



Weird one. I've just tried launching UE3ShaderCompileWorker.exe on a Windows XP machine (from a command prompt). It terminates silently without giving this error message. Is this what you meant by " When I try to start it, just for fun, it says that it is not configured properly and a reinstall might help. " ?


Could a virus scanner be blocking it from launching? If so disable live virus scanning to check.


During installation of Muvizu did you include the three components (DirectX, C++ Runtime and .Net Framework) that it says you may need? Did these installations proceed correctly?


Struggling to think of other reasons for failure to launch this executable.


Did you try both 64 bit and 32 bit versions (only possible if you have a 64 bit computer).


Dave.
2012/10/24 16:36:20
anti-aliasing Hi guys.

Firstly, sorry for the slow response on this issue, I've been really busy with other tasks...

I'm working on a proper fix in time for the next release, but in the mean time it's likely that you can get your anti-aliasing to work by starting Muvizu with the command line parameter -forceMSAA.

The easiest way to do this is to edit the properties of the shortcut with which you launch Muvizu (or make a new one) and add "-forceMSAA" (no quotes) at the end of the "Target" text field.

Cheers, Dave.
2012/5/15 15:36:04
Coming Soon... Joey Barton :-/
pages: 1 2 3 4 5