FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Particle Systems and Slab Fracture Generation

 
Post new topic   Reply to topic    blastcode.com Forum Index -> BlastCode
View previous topic :: View next topic  
Author Message
SteveSayer



Joined: 08 Aug 2011
Posts: 11

PostPosted: Mon Aug 08, 2011 5:47 pm    Post subject: Particle Systems and Slab Fracture Generation Reply with quote

Hello, I am posting this as a general introduction to some of the problems I've been having with BlastCode. I have found it to be extremely unstable, crashing quite regularly for various reasons. Here is a quick top-of-my head list of problems I have run into. I have given up on finding quick fixes, and will be starting a more rigorous testing and troubleshooting phase. Whenever I have more detail about any of these errors I will post. Until then, if anyone can offer suggestions about known issues (I'm new to using the software), it would be much appreciated.

Some general information about our setup here at Soho VFX: we use Maya 2009 and Maya 2011 on Linux workstations using openSUSE. My machine has 4G of RAM and 4 2GHz processors (though part of my testing involved running the scene on a much more powerful machine, and it still crashed). Data pertaining to each scene is stored on a network, not locally. We make use of a file referencing workflow to manage assets (though I have avoided directly connecting any referenced objects to the BlastCode sim, instead constraining objects local to the scene to the referenced control handles etc.).


1. My main current problem: BlastCode crashes on a scene with a single blast object containing one slab and a dozen or so sweeps (window and frame). An earlier version of the scene worked just fine, but now as soon as a collision occurs Maya crashes and closes. I'm not sure exactly what has changed between versions of the scene (I'm looking into that now). Things I'm considering are: translating the blast surface, editing points on explosive objects, enabling the 'Use Vert' flag on explosives, and transitioning between versions of Maya (2009 <-> 2011).

2. In a version of the scene which works fine and was saved in 'Play' mode (remember there is only one blast object, with two layers, one slab layer and one layer containing a dozen sweeps), Maya crashes if I click the 'Off' button in the Blast Window to turn off playback/recording.

3. I had a problem earlier where a crash occurred every time I tried to create a slab out of a trimmed base surface. I tried many variations on curve degree, shape, number of points, method of creation. I was also careful to delete history and freeze transforms on the surface. Crashing was still regular (never got it to work with BlastCode v. 1.7, got it to work one or twice inexplicably in v. 1.8, but only on a test surface in an empty scene. Trying to create a slab from the 'real' trimmed surface in my production scene crashed every time). I have since moved on to a workflow which avoids trims.

4. Another experience I had involved a version of the scene which would crash if I ever tried to adjust the 'start U' and 'end U' trim values for a slab. I could adjust 'start V' and 'end V' without any problems, but any change to the other dimension crashed the software instantly.

As you might imagine, having struggled with all of these issues in a week or two of using BlastCode, I am finding it quite frustrating. Any and all suggestions will be most welcome. Thank you.

-Steve Sayer
Back to top
View user's profile Send private message
SteveSayer



Joined: 08 Aug 2011
Posts: 11

PostPosted: Mon Aug 08, 2011 5:54 pm    Post subject: Reply with quote

I should also mention, very generically, that I have tried lots of "obvious solution" stuff, such as disabling secondary debris, reducing the complexity of slabs, etc. It seems like nothing helps. The main scene I'm working with is not what I would consider terribly complex; my sweeps use simple square profile curves, my slab uses no bevelling or displacement, etc. It is fairly bare-bones and so I am disappointed that it has proven to be so unstable.

Also, in an earlier scene (since abandoned) I found I had created an extra slab on an object (on a layer I intended to be used only for sweeps). I was unable to find a way to remove the slab once it had been created: deleting the associated nodes crashed the scene, and the only solution I found was to delete the blast layer entirely, which meant losing all the work I had done on the sweeps. Is there no conventional way to remove a BlastCode element once it has been created?!

-Steve
Back to top
View user's profile Send private message
SteveSayer



Joined: 08 Aug 2011
Posts: 11

PostPosted: Mon Aug 08, 2011 7:25 pm    Post subject: Reply with quote

Another issue I just remembered coming into play involves the timing of a scene.

In the BlastCode manual, mention is often made of the 'start frame.' Presumably this refers to the start frame of the Maya scene, but is it possible to change this? Of course not every simulation will need to start at frame 1, but there doesn't seem to be any central node controlling BlastCode's interpretation of when the scene should start. In one scene I've worked with, the first impact occurs at about frame 220, so I wanted to start the scene at frame 200. I wasn't able to get this to work properly. I tried setting the 'Start Frame' attribute on the BlastCode particle systems, for example, but that wasn't sufficient. The slab would only reset when the scene was rewound to frame 1, for example, so while working with that scene I always had to rewind to 1, then jump to frame 200. Not a very efficient workflow.

This issue also made it impossible for me to record a simulation starting at a frame other than 1. If I rewound to 1, then jumped to 200, the scene would simulate fine. But when I recorded that simulation for playback, the results were not usable. The damage objects worked properly, but the debris simply did not appear. I'm aware of the MasterControl node and the workflow of recorded simulations using relative time and therefore all starting at frame 1. Even accounting for this, I was still unable to get a proper recording of my simulation. The only method that ever worked was to record EVERYTHING, including the first blank 200 frames. Surely this isn't expected behaviour--what should the workflow be for starting and recording a simulation beginning at a frame other than 1?
Back to top
View user's profile Send private message
capital
Site Admin


Joined: 04 Nov 2005
Posts: 342

PostPosted: Tue Aug 09, 2011 9:15 pm    Post subject: Reply with quote

The scene in question was sent to us and these are the observations:

These issues were caused by a bad particle start time value. BC uses the particle system to initiate any debris snap. In this case, the particle shape start time was set too high. When BC attempted to emit a particle, maya refused it and this generated a crash. After adjusting the maya particle start time to a lower value (preferably the playback start time) the crash disappeared. Why this value was set so high in the first place is a mystery. Maya typically defaults to 1.

BC can start playback from any frame. However, the range slider start time must match the playback start time. Also, check out the MasterControl node for playback timing in the manual.

Another issue we observed with this scene is an astronomically high fracture map resolution. BC places no limits on resolution, however any computer will eventually run out of memory and thrash. Test to see what your machine can support. If you are using a resolution above 1000, that's probably too high. Also, understand that a fracture map produces geometry. It is not a shader. Resolution equates more geo. Typically you never need to exceed 250.

As always, please read the manual.
Thanks.

Jim
Back to top
View user's profile Send private message
SteveSayer



Joined: 08 Aug 2011
Posts: 11

PostPosted: Tue Aug 09, 2011 10:47 pm    Post subject: Reply with quote

Hello, Jim, and thank you for your reply.

Fixing the particle Start Time attribute did indeed solve one problem that I was having with one of my scenes. As to why the values had been set so high, the impact in this scene was originally occurring around frame 220. In trying to figure out how to successfully start and record a sim at a frame greater than 1, editing those attributes manually was one of the techniques I tried--along with, for example, editing the playback start time on the DebrisEmit and DamageObject nodes, as you recommend in this post. However, at some point the animation timing in our pipeline changed, which meant the initial impact moved earlier, prompting the problem. It was my oversight to have forgotten to return those particle attributes to their default values; thank you for the excellent catch.

When you say "the range slider start time must match the playback start time" I take it to mean that Maya's 'Animation start time' and 'Playback start time' values must be identical, i.e. the two values to the immediate left of the Range Slider must be the same? If this is true, this is just the solution I've been looking for--again, thank you. Had I known that earlier it would have saved me a great deal of time and trouble. I did read about the Master Control node, but my understanding is that it is used for retiming already-recorded simulations, not for adjusting how/when the simulation is to be recorded in the first place; please correct me if I'm wrong.

As a matter of curiosity, if you still have that one scene on hand, can you try editing the Trim Start V and Trim End V attributes on the slab? I have had to leave those at 0 because any attempt to change them results in an immediate crash. Trim Start U and Trim End U work fine. (I doubt very much this problem is related to the particle Start Time issue, but nevertheless I'll mention that I tested this after resetting those attributes to 1 and the crash still happens.)

I have to confess to being a bit confused about your assessment of the fracture map used in the scene. Note that I had used one of Maya's File Texture nodes to attach the jpg to the slab in question using the Fracture Map option. (The file's name does appear in the 'Fracture File' attribute slot, but it is ghosted since the Fracture File method is not being used.)

I chose this method instead of the Fracture File option specifically because I wanted to be able to use the Fracture Size U/V attributes to alter the amount of debris being created without having to go and edit the resolution of the source file. (As far as I can tell this isn't possible with the Fracture File method.)

I do understand as you have said that this image is not being used as a shader, but is being processed in order to create geometry. The fracture size I chose on the slab node was 100 x 200 (though, as I said, I would reduce this depending on whether I was doing a quick test or a full cache for rendering). The amount of debris geo created always seemed quite reasonable to me; certainly it seems significantly less than some of the examples shown on the BlastCode website gallery. Simulation is slow, but not unreasonably so.

Since receiving your response, I have tried greatly reducing the resolution of the file and converting it to a 1-bit black-and-white file instead, and have employed it as a Fracture File instead of a Fracture Map. This led to a similar amount of geo being created from a much smaller image file... However, I didn't notice a significant performance increase in simulation as a result. Am I misunderstanding the expected workflow?

This does raise a related question, though: when BlastCode converts an image or a texture into debris geometry for a slab, is this a one-time operation performed when the scene is reset (i.e. rewound to the start frame), or does it repeatedly process the image as the simulation plays? I'd be very surprised to learn it was the latter, since all the geometry divisions that make up the debris fragments are visible from the very first frame. It would seem redundant to recalculate this conversion at each step of the simulation... but I'm not a programmer, so I don't know if that's a reasonable interpretation or not.

Finally... please believe me when I say that I have pored quite carefully over the pdf document titled 'Blast Code 1.8 User Manual,' but it seems to me that none of the answers you have so helpfully provided can be found in it! (For example, nowhere that I can see does it mention that the 'Animation start time' and 'Playback start time' values should be the same for starting simulations at arbitrary frames; nor can I find any examples of 'reasonable' values for fracture file resolutions.) Is there another manual I should be consulting in addition?

Thanks again for your help,

-Steve Sayer
Back to top
View user's profile Send private message
capital
Site Admin


Joined: 04 Nov 2005
Posts: 342

PostPosted: Wed Aug 10, 2011 3:24 pm    Post subject: Reply with quote

I just ran a quick trim test on a scene and it appears to work just fine.

Fracture Maps are sampled using maya's shader. Samples are evenly placed along the U and V based on the given fracture size. This is potentially problematic, because if the samples don't fall on the fracture lines, they will be missed. The fracture file on the other hand uses every pixel in the sample process. The fracture file resolution defines the fracture size. This method will give you the most accurate fractures.

Fracture Maps are always reset at the start frame. All dynamic systems need a starting point, because time is integral part of the simulation process. BC can query the start time but not the range start time.

BC has always used a more artistic approach when it comes to destruction. All fracturing is computed at the start frame so you know what to expect in the simulation.

Hope this helps.

Jim
Back to top
View user's profile Send private message
SteveSayer



Joined: 08 Aug 2011
Posts: 11

PostPosted: Wed Aug 10, 2011 7:42 pm    Post subject: Reply with quote

That's all very helpful, Jim, thanks. I'm always ready to learn more about what a piece of software is doing 'behind the scenes,' as it allows me to work more efficiently and be more flexible.

I certainly do appreciate BC's 'artistic approach'. Being able to paint / edit the fracture patterns without needing to then go through an elaborate geometry-creation-and-instancing process is a very nice workflow.

-Steve
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    blastcode.com Forum Index -> BlastCode All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group
Blast Code, Inc. (c) Copyright 2006
Terms of Use | Privacy Statement