• 0

    posted a message on Inventor's Toolbox
    I'm working with MCP 8.02 I think. It's for Minecraft 1.6 for sure. I stepped away from this for... oh, sheesh! Almost 2 weeks! I had a new job start. And I... bought steam games. Honestly, I'm not sure which distracted me more. In any case. I'll see about taking more swings at this tomorrow. I'm thinking, as long as I do just a bit at a time, this'll get done.

    As far as making pulleys and other mechanical devices... some of those shouldn't be hard to code. A pully is just gonna be a moveable block or set of moveable blocks that is restricted to only rotating. And only rotating on one axis at that. I'll have to create some kind of item, that you can place on the side of a block. Some pivot. When you try to place a block on that side, it makes a moveable block, but the block only rotates. As far as how that interacts with rope... there's two ways to approach the issues. I can let physics handle how the rope winds around the rotating block completely, or I could give the block some kind of data value specifying how much rope is wound around it. A way to get around potentially glitchy collision physics between a rope wound around a block several times and, well, the block. But it may not be glitchy. We'll see.

    Cloth and sales? Yeah, the idea was to use the fluid mechanics to also simulate airflow, which can then push the cloth. The cloth, attached to blocks or ropes, would transfer the force along. Tada! You have sales. So yeah, that idea is still a go.

    But what should be even more a go is me working on this tomorrow. Sheesh, did not think I had been away from this for a week and a half.

    EDIT: So github. This is open source. I can't remember where I put the code online anymore (MineHippie, remind me, lol.) Putting it on github creates complications, since there are still base code edits.

    Removing all base class edits: I recently got a tip from someone who provided a java api that allows you to make edits to methods during runtime. That should allow me to ultimately remove all base code edits, if I understand what it does. Once I do that... I should have no more base code edits, which means I can make the whole thing open source without having to be concerned about the base classes that no one is ALLOWED to re-distribute. I'm still concerned though, since some of my own classes are just slightly modified versions of certain base classes, like GlobalRender. Only a few, but that's still a concern.

    So yeah, where was I when I left 2 weeks ago... multi-point collisions. I was in the process of reading a few lengthy descriptions (as in dissertations and semester-long grad coursework documentations) on rigid body physics. Why? Because the shorter descriptions only cover single-point collisions, which I already get. Yeah, I need to get back to those. I remember I found the particular sections I needed to cover. I need to find where I saved those pdfs.
    Posted in: WIP Mods
  • 0

    posted a message on Inventor's Toolbox
    Quote from anicet74

    wait,does it mean we will have a release soon?
    really nice job on this mod,I can't wait to try it out,seems a lot better than old physic craft


    Eh? How does it seem better when nothing new has been released yet?

    I wouldn't say SOON. I'm taking this slowly, hoping to work at a pace that I can continue with when Summer's over (unlike when I worked on this last Summer.) I also haven't heard from MineHippie or CodeOrigion in a while. So I don't know if they have any plans or contributions coming.

    Looks like the "bugginess" in my visualizations wasn't really a bug, but scenarios not accounted for in the algorithm. It includes elastic collisions, which is a step ahead of the old PhysicsCraft algorithm, but it still has a problem that the old PhysicCraft algorithm had too. I created a stop-gap in that original algorithm to keep things from exploding, but I never really solved the issue.

    A lot of rigid body physics explanations on the internet try to keep things simple by consider two objects colliding at one point. So, in Minecraft, that would be the corner of one cube colliding with the face of another cube, for example. But the algorithms you derive from that don't take into account collisions that involve multiple collision points. What if two corners of a cube hit the ground simultaneously? What if more than 2 objects hit? (multi-objects never came up for me, since I just had world-to-ship collisions before. But the multi-point collisions were an issue.) If multiple collisions are happening on an object at multiple points, the force at any one of those points is affected by the forces at all other points.

    So, I need to research multi-point collisions for rigid bodies.
    Posted in: WIP Mods
  • 0

    posted a message on Inventor's Toolbox
    Looks like I'm gonna have to take a detour and rework some of the rigid body collisions. I've gotten most the data saving and loading on the server side, and transferring to client on entering the world. But there are a few pieces of data related to collision detection and rigid body physics that I want to hold off on. Some of the rigid body algorithms I used were sort of stop gaps until I found out better ways to detect collisions and ways to calculate elastic collisions between ships. The thing is, what I send over the server regarding these details depends on what algorithms and what data I'm using. If I set up server packets for the current algorithms, I will have to revamp that whole code as soon as I fix the rigid body physics. I might as well improve the rigid body physics now before I set up the packet sending, so I don't have to rewrite a bunch of connection code.

    I did some separate coding for visualizations outside of Minecraft, using modified versions of the code I created in MCP. I got the hydrodynamics algorithm working that way, and did a few things with cloth simulations, and I was working on an improved rigid body simulations with elastic collisions. Right now, there are some shortcomings to the improved algorithms, as well as some odd errors I'm getting. I'm gonna see if I can iron out the kinks in that visualization, then transfer the code over to MCP.

    The plus side of this is, when I do finish updating to the current version of Minecraft, some of the shortcomings in ship/world collisions will be ironed, and there should be ship to ship collisions.
    Posted in: WIP Mods
  • 0

    posted a message on Inventor's Toolbox
    Okay, so the physics and controls seem to be working fine. I can place a block, I can move it around. It shows believable rotational dynamics and buoyancy. It collides with world blocks. So all that stuff is working just fine. Not surprisingly, since all that code is totally separate from any base code for the most part.

    Next step: Back when I was updating for 1.3, I didn't finish resolving all packet sending issues for the new server/client singleplayer system. I've gotten it all to save fine (I think.) What I need to do is have it load from file ONLY on the server side, and then use packet sending to create the ships and set their chunk status, transforms, etc. on the client side. And have it work of course...

    After that, I'll figure out why the heck I can't add blocks to moveable blocks I've created. And after THAT, I'm gonna go back to filtering base code edits down. I only did about half the base code edit removal when I first took a swing at it after discovering Java Reflection. After I've REALLY TRULY removed as many base code edits as possible, I will move over to MCP 8.0.3 (or a newer version, if one comes up.) It will be easiest to transfer code over when base code edits are minimal. It will also be much easier to transfer code over to FORGE when base code edits are minimal.

    Between the block adding and base code filtering steps, I'll probably post a vid to show how it's functioning so far.
    Posted in: WIP Mods
  • 0

    posted a message on Inventor's Toolbox
    Well, I got past the reference fixing stage and the see-what-blows-up stage. Now I can load minecraft, mine blocks, walk over to water, see the water blocks highlighted, as happens in my mod, right click, and... not see anything placed. But the important thing is, ALL EXCEPTION ERRORS ELIMINATED. YAAAAAY! Okay, if any of you coded, you would know why I'm happy about this.

    Anyway, as soon as I rightclicked the water with a block in hand, the files for a ship are all created, and chunk data is saved. So everything that needs to be happening to make the ship IS happening. I can think of a few things that could be going wrong.

    -The ship's "transform" (a matrix that determines the ships location and orientation) is not being created properly. As a result, the block doesn't end up where it's suppose to. It could be anywhere in the Minecraft world. I've had this issue before.
    -The block setting code may not be working. The methods for setting the block id for a block space in a chunk have changed a bit since I last worked on this. There could be something wrong in my code that doesn't take into account changes.
    -Rendering code could be messed up. Some of that's been changed too, and I'm not sure in what all ways.

    I'll be looking into these various possible problems and trying to find the culprit. On to further progress!

    EDIT: Both block setting and transforms seemed to be fine. So I started giving the rendering code a closer look. Turns out, there were a few code edits in my original code that I didn't carefully mark. I didn't port them over as a result. It ended up referencing base rendering code, instead of being redirected to alterred versions of the rendering code that it needed. So THAT was a major flaw, that's now fixed. Buuuuut the blocks still aren't showing. Which means there's something else ALSO causing the blocks not to show. Back to code sifting.

    EDIT: Okay, so I got it to show... sort of. To recheck if there's anything else wrong with matrices, I removed the physicscraft transformation matrix input from opengl. The first block you place when creating a ship gets put at (0, 128, 0) coordinates in the ship's block coordinates. Without the physicscraft matrix input, that should show up at (0, 128, 0) in the REAL world coordinates. So, I disable the matrices, I find some water at about, (-10, 65, -10), I right click the water, and then I look up in the sky, and sure enough, there's a block there at what's probably (0, 128, 0) in world coordinates. So it looks like there IS something wrong with the transform matrices (since it will render, and the block definitely is there, but it doesn't end up where it should be when the matrix input is ENABLED.) But this is good. Now I can incorporate little bits of the transformation matrix code in at a time, predict what SHOULD happen to the block in the sky, and see what happens instead. So, I input a slight physics craft translation matrix that should move the block a little bit in some direction. Does it move in the wrong direction? etc. etc.

    EDIT: Okay, so the problem isn't matrices. They're working just fine. The problem is frustum clipping issues. I've had this problem before in various forms. Even in the mods most stable version, particularly large ships would have issues where certain outer chunks just weren't visable. It's been a long time issue for me, trying to solve this completely, but it's always a pain in the butt when it comes back on even simple tests. The idea is, the game's rendering engine doesn't bother processing any information about chunks that it knows aren't in your vision (so if it's a chunk behind you, it doesn't care. Not gonna get rendered.) In order to DETERMINE what chunks you see at a given time, it takes your location, the location of chunks, your look direction, and calculates. From what I can tell, it's not taking into account the physmatrix transformation when it decides what to render, but it does take into account the transformation when it finally DOES render. What I notice, is if I move the block lower, it becomes invisible as my viewing angle goes below a certain angle. I have to be looking up for the block to render, even if the block is in front of me, not above me. I think it still thinks the block is up in the sky. So now I have to look into the visibility clipping code. I may have some OTHER piece of code that I haven't ported over. Something I didn't mark. I look forward to the day this problem is ENTIRELY resolved, and objects don't go invisible for unknown reasons.

    EDIT: Yep, found some more code. Working on it now. I really gotta make sure to keep these things marked. It saves time.

    EDIT: Found ANOTHER unmarked code edit. The blocks are showing for good. Now I'm really starting to feel guilty for leaving Codeorigion and MineHippie with this mess. No wonder they had trouble getting this to work.

    Okay, next step. Right now: reactivate physics, and see if it responds probably to gravity, buoyancy, controls etc. I notice I can't add any blocks to the one I've placed, there's another bug I need to fix. I think after I get those two things fixed.
    Posted in: WIP Mods
  • 0

    posted a message on Inventor's Toolbox
    Update: Found some more base class edits. Moved them over. I should now have all the code in the MCP 8.02. I've resolved most of the referencing issues needed. Just two more major classes I need to work on. After that, I go into the run-program-and-see-what-blows-up phase, checking error stack traces to find issues other than referencing. After I get everything to NOT blow up, I see if I can still place blocks on water. If not, I start tracing the code execution to find out where it's SUPPOSE to be placing blocks (it's been a year. I remember enough to make this easy, but not enough to remember stuff precisely.) Figure out what's not doing what. Once I get the blocks placed, make sure the controls work and start analyzing the changed save system. The save system is what I was looking into last time I was working on this.

    Quote from TTFractal44

    Any time the player creates a new moveable structure, a new MCAnvil Dimension is created to store the craft. A number of things would be different about this special type of dimension: no terrain is generated, only the minimum number of chunks needed are stored, and the dimension cannot be visited by the player. The blocks are stored in an mca dim because any block mechanics, whether from Mojang or third party mods, would work exactly the same there as in the real MC level. Then the crossover magic needs to happen to make these constructions within false mca dims appear in the level as a moveable, physics-affected entity (Not a normal Minecraft entity). This is where it gets a little messy in terms of coding but it remains an elegant solution: any time a block, or code from some mod, within the false dim calls for a polygon to be rendered, do the necessary geometric transformations to render it in the right position in the real level. This should ensure that blocks all render properly. Something very similar could be done with the collision meshes, where every time a block in the craft is changed, the terrain collision mesh from the fake dim is copied over to the entity that represents it in the real level.


    That's basically what I did, except I didn't wrap it into an entity class. If you were thinking wrapping into entity code would make it easier to rotate, move, etc. that's what I originally thought. But that turned out to be wrong. The transformation mechanics set up for entities is actually very primitive. I needed to write something more general.

    You asked what physics engine I'm using. I'm not using any. I wrote everything related to the physics simulations from scratch. By the time I started researching physics engines, I had already gotten pretty far into this project. I eventually decided it was best to build it from scratch too, since that would give me a chance to see how to make the engine specifically optimized for Minecraft (which is no small matter. Minecraft is an oddball world to put physics in, but it opens up major opportunities for optimization that wouldn't be possible for more general physics simulations.)

    Quote from TTFractal44

    Obviously, the moveable structure's blocks don't exist as blocks in the level, and vice-versa. But, there should be this kind of crossover anywhere a calculation is made based on surrounding blocks. It may be block updates, redstone signals, mob pathfinding, or even lighting! Here's how it works: whenever the function for getting a reference to a block at a certain position is called, in anything besides level saving or rendering, it should read both the main level, and the equivalent position inside any nearby moveable structures. That is, it reads the current world for the block, and returns it unless the block is air, in which case it proceeds through the list of moveable objects in existence using a nearest-neighbor algorithm (really simple transforms and rounding) to get the block. If the function is called from on-board a craft, and the block requested is air, call the one for the main world. What this is is a simple way to do some really awesome things: Redstone works from craft to world, from craft to another craft, and from world to a craft.
    Lighting is realistic! A light on a craft lights up the surrounding world, and the craft respects the world's block lighting. Mods where a block needs to change another block (Redpower Breakers and Deployers come to mind) will work as expected with this system.
    I seriously suggest you consider implementing this. It is simple, elegant, and likely to enable many desired features.


    I'm currently doing this for collisions. Still, I want crafts to be completely interactive with the world and other crafts, as you suggest. But it'll take time to get there. I want to get the physics engine more built up first. But this is definitely on the to do list. Especially since part of the idea behind this was to add in more physics-based mechanical machinery. Rather than creating special blocks that do special tasks, you just use the blocks you already have. So, for example, a moveable block with redstone on it might slide along a path way. If it intersects with another block with redstone on it, it sets off a signal. Maybe the block slides because it's inside a larger device that's tilting. The response it makes to that tilt with the connected redstone is perhaps activating some time of propellor to rebalance the structure. Ideas like this might be useful to, say, stabilize a zeppelin or other aircraft, prevent stalling or spinning out of control, etc. But the important point is that you didn't use some special stabilizing block. You just thought of a clever way to take advantage of the physics. That was one of my main goals for this mod. What you could do with it depends on how clever you are. What you do with it is not necessarily something that I or any other coder for the mod anticipated.
    Posted in: WIP Mods
  • 0

    posted a message on Inventor's Toolbox
    Quote from Viktor_smg

    Judging by what most mods do,you are trying to make the physics objects be "mobs" that are affected by physics and are easily expandable,right?In that case the only stuff you would need to do is fix some of the more more common mob bugs where they sink into the ground,etc. And make it so that stuff doesn't just "fall"..


    Nope, that's not it. The moving blocks aren't entities (i.e. "mobs"). Nor can they be. If they were, I wouldn't have any of the tools available associated with Minecraft chunks that allow me to create large complex ships that can be continuously crafted while still affected by physics. And to the degree I have to edit Entity movement, I still have to edit the base classes.

    Honestly, a ton of the code (95% of it) is outside of base classes already. What's still left, Forge cannot help me with. Some of it, I think I can still find ways to edit out. But in either case, Forge doesn't help. And until I do find ways to move more code out of the base classes (which again, Forge won't help me with) this mod will STILL be incompatible with other Forge mods, whether I make it a Forge mod or not.

    So here's my plan, and this is what I'm pursuing now: I've ported my classes over to MCP 8.02 (Looks like I already need to move over to MCP 8.03) I have also re-inserted my base code edits into Minecraft.java and EntityRenderer.java. The ones I had in the Entity.java I'll pass for now. Those are related to Entity physics, which I'll forgo in my first tests. The first thing I'll get up and running again is the moveable blocks. I'll also try to fill in some gaps that I had with collision physics, new stuff that I've worked on in java since I last handled the mod, but never added into the mod. Once I get that solid, I will start approaching entity physics. Then I'll re-integrate rope physics. I may try to incorporate the fluid mechanics that I developed for visualizations separate from minecraft (and sometime after I left this mod) back into the mod while I'm still working on moveable blocks. One major part of the block physics is buoyancy. Any system I set up for buoyancy before I add in fluid mechanics will be overhauled by fluid mechanics later anyway. So I might as well start trying to integrate it in early.

    Right now, I'm trying to resolve all referencing issues in the code from method renaming or reobfuscating, and get the basic elements of the mod related to moving blocks up and running again. Then I'll go from there.

    I'm gonna try to get a little done each day, and not do too much at once. Last summer, I really got sucked into this and got a lot done, but I was pretty exhausted with java coding afterwards. I want to approach this at a pace that will me to continue working on this without getting tired, and at a pace that will allow me to CONTINUE working on this once I get busier after this summer ends. I dropped the project after last summer ended. I don't want that to happen again.

    Once I get the "skeleton" of the mod up and running. I'm gonna see about removing more base code edits. Once I've distilled those edits down as much as possible, I'm gonna see about porting the mod over to the Forge MCP. If I have most of my code external to the base classes ANYWAY, I bet I won't have to change much for Forge. And if THAT'S the case, it may be very easy for me to have versions for both Vanilla and Forge.
    Posted in: WIP Mods
  • 0

    posted a message on Inventor's Toolbox
    If it's bugfix stuff, I doubt it will affect forge that much. I'm gonna keep learning forge.
    And sorry for being cranky.

    EDIT: Okay, went through the first couple of tutorials, and everything worked for the most part. Now time to skip straight to the advanced stuff related to hooking, etc. since that will probably be what I need to get most of the code in there.

    EDIT: It could just be me, but what I just read makes hooks sound like what EVERYTHING in Forge is. Some way to add something in your own separate class rather than in the base code (a new recipe, a new block, etc.) But I was under the impression that it was more advanced then that (i.e. you could use hooks to interject execution of ANY kind of code you've created anywhere along the way in the base code execution. But you wouldn't have to put it directly in the base code.)

    This is where things get troublesome for me, and the reason I didn't use modloader originally. A lot of what I'm doing isn't adding blocks or new devices. It's making old things do stuff that they were never intended to do within the minecraft code architecture (i.e. block creation, rendering, etc. is all coded under the assumption that blocks are fixed on the world grid, and can't move. My mod scraps that by interjecting a lot of code at strategic points in the execution. If I can't interject code execution at arbitrary points, that's gonna cause issues. If Forge is no better than modloader on this point, this will be troublesome. If the hooks only build off the architecture, and don't allow you to directly CHANGE the architecture, then I don't quite have what I need in Forge.

    Chances are though, I'm still missing something about Forge, and have to keep researching.

    EDIT: Been chatting on the Forge forums. Looks like there isn't anything I'm missing. I'm pretty sure I can make this mod Forge compatible without making it Forge dependent. I know enough about reflection to do a lot of what Forge does already. The base class edits that I need without Forge, I still need WITH Forge.
    Posted in: WIP Mods
  • 0

    posted a message on Inventor's Toolbox
    Quote from Viktor_smg

    Pro tip:Always give a sign that you are ACTUALLY coding,making the mod,etc. when it is taking too long.Examples can be:videos of buggy features/just features;Prereleases;Pictures.Right now...we can consider this dead as,really,none of you guys(people coding @ this) are like "ima codin now'ppl,and don't spam about update and stuff..."


    Pro tips:
    -People have lives. They aren't necessarily working on this right now.
    -They are not accountable to posters.
    -If they had something to show you, they would have.
    -Since they haven't, they don't.
    -If it's dead, why are you posting?
    -People can spam post. That won't make the modders magically have an update.

    But enough of that. I came back on to see what's happening with Forge. If I jump back into this, I need to know where to start. I've been off of minecraft for SO long, only semi-sucked back in by a friend showing me TechnicLauncher a few days ago. I need to know where the mod-compatibility community is. It seems like the latest version of Forge is for Minecraft 1.5.2, but the latest version of Minecraft is 1.6.1.

    First question: Is forge still the primary mod compatibility tool for modders? Is there something new out there?
    Second: Are people still keeping their 1.5.2 versions of minecraft? What's the ETA on Forge for 1.6.1?
    Third: Were there versions of Minecraft between 1.5.2 and 1.6.1, and if so, how many?
    Fourth: How old is 1.5.2?

    I'll be researching the answers to these questions. But if anyone can answer these questions here, that would be great. My version of the mod is still the pre-forge direct hack of MCP. If I'm gonna jump into learning Forge, I'd like to make sure I'm not barking up the wrong tree, when there might be a mod installer, or something else out there, with better compatibility standards to work from.

    EDIT: So, I found the version of Forge for 1.6.1. The site just hasn't added a forum topic for it yet. In any case, that answers that question. I'm installing it. I'm gonna assume for now that Forge is still the main method for mod compatibility and start skimming through the tutorials.

    EDIT: aaaand now I'm reinstalling it, since the previous ridiculously long install ended with errors, probably because java was out of date. Updated. Reinstalling. Fingers crossed on this ridiculously long install (so many .ogg files!... Installed at a rate of 1 per second! Why!)
    Posted in: WIP Mods
  • 0

    posted a message on Inventor's Toolbox
    Okay, so, just sifted through my backlogged forum mail. Several people offered to help on this mod. I hope they found their way here. I sent them all the link just now (but those messages were SO old. Man I've been gone a while.)
    Posted in: WIP Mods
  • 0

    posted a message on Inventor's Toolbox
    I would like to thank my friends for introducing me to League of Legends, and therefore sealing the fate of any free time I might have had to work on this project for the past couple of seasons (the rascals!) Actually, no. Coding is tiring, and I needed to use my free time on R&R. I graduated this spring, so I had enough on my plate. But it's Summer now, and while I have some big things coming up, I'd say I have time to look at this again. Any immediate questions codeorigin or minehippie? Other than "How could you abandon us?! Why? WHY??!!"
    Posted in: WIP Mods
  • 0

    posted a message on [1.2.5] PhysicsCraft Pre-Beta [0.18]: Cloth Physics and Rope Collisions Preview Vid Added
    It used to be called Vec3D in older versions of Minecraft. I was using it for vector math for a while, and added methods to it for my own purposes, but I eventually found that Minecraft keeps a pool of all created Vec3D objects, and seems to even alter them when I don't want it to. So I just created my own class, PhysVector. Even so, I occasionally needed a way to create Vec3D objects for raytracing and targeting objects, since Minecraft's code for targeting objects at times required Vec3D's. I think there are some base class edits in Minecraft.java related to this. I'll try to explain them sometime soon.


    EDIT: I also really should put up my revised code. I recall revamping calls for the new Vec3 name. There are probably other examples of this. I'll see about uploading the newer versions of the code as well.
    Posted in: WIP Mods
  • 0

    posted a message on [1.2.5] PhysicsCraft Pre-Beta [0.18]: Cloth Physics and Rope Collisions Preview Vid Added
    For those interested, here is my example simulation for fluids. MAKE SURE you click inside the applet after it loads, otherwise the controls won't work. The controls are specified on the page:

    http://micaiahchisho...SimApplet3D.htm

    I specifically provide ways of increasing and decreasing the "resolution" of the particles so that you can see that at lower resolutions, even with just 2 or 3 particles in a relatively large area, you can still get a pretty good fluid behavior. Basically my test for Minecraft would be, "do these particles flow through a 1 by 1 meter block opening?" If they do so properly, then it's good enough. Most smooth particle hydrodynamic simulations like these are done at resolutions a thousand times greater. They also use c++ and multithreaded programming to really make the algorithm soar at those resolutions. This is unreasonable for something like Minecraft, coded in java and designed for any computer. But thankfully, Minecraft doesn't NEED high resolution fluids. I would say decrease the fluid resolution in that applet 2 or 3 increments, and you have what I had intended for Minecraft.

    You may look at this applet and think, "What do point particles have to do with fluids?" This is just a way of seeing what the fluid algorithm does. It's not a way of visualizing it. As an example of how I might turn this into Minecraftish fluids, visit the following page:

    http://www.exaflop.o...ocs/marchcubes/

    If you want to see various ways people have turned these particles into a single continuous fluid, just google "smooth particle hydrodynamics" and check out some youtube videos. Most of the examples are way more complex than what is needed for this algorithm.

    The next step is obviously to find a good way in Minecraft to render fluid based on these particles' locations. A test could be as simple as, "if there is one particle in a given block of minecraft space, render water at such and such a level. If there are two particles, render it at a little higher level. If there are 5 particles, render a full block." This is a poor test, since we now have multiple grid spaces with moveable blocks. I don't plan to use this simple water level algorithm, but it's just an example of how this can be turned into minecraft fluids.

    Actually, the next step is mix this algorithm with general rigid body (block) and soft body (mainly cloth) collisions. I'll get back to you guys when I get there. I can give you the code for this applet here if you're interested, but it's best to wait until I resolve other issues.

    There's one more issue I haven't mentioned. This algorithm obviously can't be used to simulate fluids everywhere. Having an ocean made up of these particles would be ridiculous, and far too expensive. Particle simulation would occur in small cells where physical phenomenon are happening. For example, if there's a boat in water, the area immediately surrounding it out to a small distance might be handled using these particle simulations. There might be a small cell for wind particles anywhere a cloth might be. Having cells of particles follow certain physics-affected objects, and then perhaps having those cells of particles interact if they ever merge, is a whole other challenge to consider when incorporating this meaningfully in Minecraft.
    Posted in: WIP Mods
  • 0

    posted a message on [1.2.5] PhysicsCraft Pre-Beta [0.18]: Cloth Physics and Rope Collisions Preview Vid Added
    NBTTags are used for entities. I am saving the blocks in my subworlds the same way blocks are stored in the real world. This may not be optimal, but optimized saving wasn't a big deal to me. Kovu, if you can explain some of the bugs, I might be able to help. Also, probably the reason you're having issues with entities is that one of my major base code edits was to the Entity class (or was it livingEntity?). I added code that handled collisions. I added it near the code to regular collisions. I'll try to explain it soon.

    I don't think I should explain what I was going to do for fluid simulations, since I think it is best if I go ahead and get that working myself. It requires a rethinking of an algorithm called smooth particle hydrodynamics. The code I have in PhysicsCraft right now is buggy (and even if it wasn't, isn't functional in any useful way). I have a much better version implemented as a demo for a resume. I think what I'm gonna do is modify that demo to be included with another cloth simulation demo. Once I have the two functioning together, I'll have the code available for fluids that works pretty well. Hopefully, some people here can figure out how to implement it in Minecraft. I don't have the time mess around with Minecraft updates and other shenanigans. I'll also be working on a demo for rigid body interaction with fluid simulation. That will be useful block-fluid interaction.

    If I were you guys, I wouldn't spend too much time thinking about fluids right now. These algorithms are usually researched in graduate schools. If you feel up to it, that's your call, but I come from a physics/computer science background, so it's up my alley. I may save you a lot of time with some of the examples I'm setting up as part of a resume.
    Posted in: WIP Mods
  • 1

    posted a message on [1.2.5] PhysicsCraft Pre-Beta [0.18]: Cloth Physics and Rope Collisions Preview Vid Added
    I'm so sorry MineHippie. I haven't checked on the thread in a while. I didn't realize how obscure I left the code. I'm gonna just start trying to explain bits and pieces here and there as I can, and hopefully I or someone else can gather my explanations on a page somewhere on the web. But it'll be a start.

    To begin with, in the renderWorld() method in EntityRenderer, I add a call to PhysRenderer.modUpdate(). The modUpdate method executes a lot of the code associated with my mod in one way or another, including rendering all things physics. The reason I call modUpdate at the point I do in renderWorld() is because there's a lot of information in OpenGL regarding camera position, lighting, depth maps, etc. that gets generated at the start of renderWorld() and then gets deleted at the end. I need a lot of this information in order for my moving blocks to render properly relative to everything vanilla in the world.

    Now, in the PhysRenderer.modUpdate() method, there's a call to PhysManager.tick(). This method basically calculates where everything controlled by physics (other than moving blocks (the biggest part)) ends up over the next "tick", which is a small increment of time (usually the time between animation frames in this case). It's about 15 milliseconds, and basically calculates where everything will end up at the end of those 15 or so milliseconds. I'm skipping over a bunch of code here and there, so if there's something you'd like an explanation on, just ask. In PhysManager.tick(), you'll see several other calls to tick() methods in other classes.

    The first is PhysFluidManager.tick(). This one doesn't do anything important right now. It's code from my development in fluid physics. It also has nothing to do with buoyancy right now, or why blocks float. Although I wanted to try having the buoyancy controlled in the future by the fluid physics I was implementing.

    The next is PhysManagerObjects.tick() (by the way, the order of these may have changed. I'm looking at my MCP 7.2 code, which is not what's on the online repository. I think it's the same though.) This tick() calls the physicsTick() method on all PhysEntity objects (at the current time, these are PhysClothEntity and PhysRopeEntity.

    Now, stepping away from this path of code, lets head over to Minecraft.java. There's a place where I call motionTick() on all PhysWorlds, it does a similar thing for the moveable blocks as the other tick() methods did for other physics stuff.

    I'll try to specify where specifically the modUpdate() and motionTick() calls were later. It may not matter at this point, since it may have to be changed. I guess it depends on what version of MCP you're running, and now I hear there's a Minecraft 4.5? Dang.

    There's a lot of other base code edits other than those two calls, but they're two of the most important method calls.
    Posted in: WIP Mods
  • To post a comment, please or register a new account.