CrazyDave - all messages by user

23/04/2013 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.
23/04/2013 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
11/04/2013 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
12/12/2012 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
05/12/2012 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 :-)
05/12/2012 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
05/12/2012 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
05/12/2012 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.
27/11/2012 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
23/11/2012 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
22/11/2012 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
22/11/2012 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
24/10/2012 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.
24/10/2012 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.
15/05/2012 15:36:04
Coming Soon... Joey Barton :-/
03/05/2012 20:15:22
softwares to change the voice You could try installing Reaper (it's free) and using that to record your audio.

http://www.reaper.fm/

That allows you to use VST plugins which great for real-time audio processing. Here's a free voice changer that would work:

http://www.g200kg.com/en/software/rovee.html

and here's a (probably better) commercial one that has a demo version:

http://soniccharge.com/bitspeek

This might be tricky to set up however if you have not used VST stuff before. You might need the ASIO4ALL driver for your pc if you do not have a genuine ASIO soundcard.

http://www.asio4all.com/

But it would work eventually!!

Dave
edited by CrazyDave on 03/05/2012
10/04/2012 17:07:21
Feedback Thread - v0.19b release (January 2012). Danimal wrote:

I'm not sure why all this "teleport" business got thrown into the mix. Used to be I'd do one pass with all of my character actions in a row and then move them around on the timeline to where I wanted them for better control. Then I'd add any movement the same way: all in one shot them position it where I want it. More precise control, and it's markedly faster than having to do everything in a linear fashion, a process requiring mulitple starts and stops of playback and recording.


Good point, and no one has really pointed out this problem before. I'll have a look and make sure that this workflow is preserved in the forthcoming release. It's certainly possible (and desirable) that this method of recording still works with the teleport system. In fact the teleport system does add some serious advantages in other areas (specifically that action animations are now allowed to move "off the spot" e.g. a moonwalk that doesn't return to the start position).

What is necessary is that when recording movement over the top of actions, the actions' recorded locations are modified so that the path is continuous. I was under the impression that it currently worked like this but maybe it was broken in the last build: I'll have a look.

Danimal wrote:

Now there's all this actions turning green and red and teleport this and that. Several times I'll go to reposition a character's movement bar and he just vanishes completely. Even with no actions at all, he's just gone. Not deleted, the bounding box with his name is still there and I can "Move to" him in the Scene Window, he's just invisible.


I believe this bug was fixed recently internally and will not happen in the next release.
05/03/2012 16:41:57
Character circles after movement I think that I fixed this internally a few weeks ago so it shouldn't happen in the next release.

One 100% reproduction was to draw a path, wait for the character to catch up with the locomotion guide without releasing the mouse button then draw another path and release the mouse... the bug's been closed since 23rd Febuary so it's hopeful that there are no other ways to make it happen.
edited by CrazyDave on 05/03/2012
30/01/2012 15:35:12
transparent video Dylly wrote:
I can't find the thread which gave the alteration that had to be made to Muvizu to allow transparent video...or do I still need to make that alteration in the new incarnation?



Still the same method and still works.
30/01/2012 11:28:34
How do I move a character then turn him? ukBerty wrote:


Try it - record three separate sections of walking then delete the middle one.

Maybe one of the Devs would like to comment on the thinking behind this development ??

Berty


Yup, it's a new feature. The actual reason behind it is to allow non-movement animations to move "off the spot" e.g. a Moonwalk that doesn't have to return to where it started. The problem with allowing these animations is that you could record a string of movements near the end of a scene, then rewind and perform an "off-the-spot" action at the beginning of the scene which would mean that the character is then not in the correct starting position for performing the movements: there will be a teleport. It wouldn't be right to just delete the movements or to fix the path automatically so a system has been put in place that allows the user to leave the teleport as it is (a red block signifies a teleport) or to make the path continuous, which will in turn alter the start and end positions of the movement.

Dave
pages: 1 2 3 4 5