Hi Sanjeev,
First of all, yes, Hamish is thinking of the same solution I am. However, it sounds like you probably want to have the flat list as your main list - so that would be your current Material list. Then you want a second list called something like Material Hierarchy.
To populate this list, create an action that copies the data from the main Material list into the Material Hierarchy list, with the parent coming from the Parent Material property (and all the other properties going into matching properties in Material Hierarchy). You'll have to run this action any time the structure of the list changes, or any times are added or removed, or any of the properties change.
Once you've got this hierarchical version of the list set up, you can rewrite your modules, Module 1, Module 2 & Module 3, to use Material Hierarchy instead of Material, and then finally your formula for Cost can be taken from these hierarchical modules using a lookup. Keep the names and codes of the two lists exactly the same so your lookups are simplified.
One thing to be careful of is that using simple properties to define the structure of a hierarchical list doesn't do any error-checking, so you need to be careful that the user doesn't create loops in the parent-child relationships. For example A's parent is B, B's parent is C and C's parent is A.
Secondly, instead of importing directly from Material into Material Hierarchy, you could consider setting up a module based on Material and then defining a view on that module to do your import from. This allows you to have different versions of the import, validations to prevent duplication and so on. It's a bit more work but it's good practice.