Jump to content
  • Advertisement

Komal Shashank

Member
  • Content Count

    33
  • Joined

  • Last visited

Community Reputation

147 Neutral

About Komal Shashank

  • Rank
    Member

Personal Information

  • Interests
    |programmer|
  1. Komal Shashank

    Calculating the moment of inertia of a 2D capsule

    Oh, I thought it was part of a much larger research paper or something. Helped me nonetheless. By the way... Update: I got it working. It behaves as intended now. I finally understood what was wrong. I thought the parallel axis theorem worked with any two parallel axes. One of them has to be through center of mass, got it.  :D
  2. Komal Shashank

    Calculating the moment of inertia of a 2D capsule

    That's awesome! Thank you so much, Irlan Robson!  :D Now it makes so much sense. I'm going to try and implement this and update this post when it works. Thank you very much!   @Dirk Gregorius: I think I've seen your paper before but I guess I had trouble flattening it to 2D. Thank you, guys.  :)
  3. Hello... I am trying to calculate the moment of inertia around the center of mass of a 2D capsule which I divided into a rectangle and two semicircles. C is the center of mass and the axis of rotation passes through this point.     I know that the moment of inertia for a semicircle around an axis perpendicular to its plane passing through the center of its full circle is 1/2 MR² where M is the mass of the semicircle and R is the radius (correct me if I am wrong). Here, for the two semicircles, it is points A and B. For a rectangle, the moment of inertia passing through its centroid is 1/12 M(L² + W²) where M is mass of the rectangle and L and W are its dimensions. Here, the centroid is the same as center of mass C.   According to the Parallel Axis Theorem, the moment of inertia around an axis parallel to the existing axis is the existing moment of inertia added to the mass multiplied with the squared perpendicular distance between the two axes. Here, for the semicircles, around C it would be 1/2 MR² + M(AC² or BC²).   The total moment of inertia for the capsule would be the sum of its constituent moments of inertia, so it would be Rectangle's + 2 * (Semicircle's). Based on this, this is what I did, but I don't think I got it right because my capsule is jittering all over the place and not rotating as intended. float momentOfInertiaOfRectangle = (massOfRectangle / 12.0f) * ((extentLength * extentLength) + (extentWidth * extentWidth)); float momentOfInertiaOfSemiCircle = massOfSemicircle * ((0.5f * m_CapsuleRadius * m_CapsuleRadius) + (extentLength * extentLength * 0.25f)); float totalMomentOfInertia = momentOfInertiaOfRectangle + (momentOfInertiaOfSemiCircle * 2.0f); Please tell me if I did anything wrong and clarify this for me. Thank you.
  4. Komal Shashank

    Pronounciation of GUI

    Well... Fancy that. Creating a poll topic and forgetting it for ten days and then coming back to see that it's a hot topic with 55 replies. That's quite overwhelming, I must say. Anyways... From what I've seen in the replies and the poll results, a lot of people prefer 'gooey' and that is quite understandable - since it is an American invented word and the tendency of the American language to lean towards the casual pronunciation of words. Although, I don't think it is hard to imagine that majority of the people in countries like the UK and India say it as 'jee-you-eye'. Everyone in my college said 'jee-you-eye'. Never did I once hear the sound 'gooey'. I was always taught it as 'jee-you-eye' (I'm Indian, by the way). Imagine the word GUI being said in a proper high class British accent, from which the Indian accent is derived (the actual one, not the Apu Kwik-E Mart one), and you can see the sound 'gooey' sounds really odd and does not fit well in context. But, then again, it's a matter of preference. For me, I prefer 'jee-you-eye'. It sounds better to me, anyway. This topic gave a really interesting insight to what a lot of people think and prefer.
  5. Komal Shashank

    Pronounciation of GUI

    What's with all the people pronouncing GUI as 'gooey'? I always thought it was pronounced JEE-YOU-EYE! Isn't GUI an abbreviation rather than an acronym? What do you guys think? What's your preference?   P.S.: Please don't flame.
  6. Thanks for the replies, guys. I really appreciate it.   @Sean: I know that uint8_t is a typedef for char, but since I was using it to pack my bits to write my bytes, I thought I could use it for this too. Apparently not. However, now I plan on using long for the canonical codes and then putting them into the vector<bool>. I'm trying to master STL for now, so I'm trying to avoid touching the Boost libraries. But, thanks for your advice and very informative post. I did not find this information on googling.   @fastcall22: OK... So, if I want to write the bit lengths (int or long) to the file header, how would I do it? I want to write them in such a way that, regardless of how I write them, I want to read them as the same values are they were before writing.   @SOL: I do have a tree and they are generating a vector<bool> for each symbol. But they are not canonical. And that's why I want to generate the canonical codes for each symbol.
  7.   Well, I thought so too... But when I write the number itself to the file, it is writing the ASCII value to the file. I assumed it might do the same thing even when I store it in a bit container. So, I thought I might need to do a conversion or something. For writing to the file, I figured out the way of packing bits into bytes to write the exact number. However, this I wasn't sure of. Thanks for the code, though. I'll check it out and see how it goes.
  8. I tried using std::bitset. However, if I'm iterating through the list of symbols, I am not able change the size of the bitset every iteration to match the symbol's corresponding bit length since bitset must have a constant value. for(every symbol, bit length) { std::bitset<bit length> Bits(code); } Error: expression must have constant value. Is there any alternative to this?   EDIT: fastcall22, that is not my problem. I can write bits to the file fine. I want to put these bits of variable sizes into a list (or map) of vector<bool> for each symbol so that I can use that to encode the corresponding symbol to the file.
  9. This is not homework. I'm trying to generate canonical Huffman codes as defined in http://en.wikipedia.org/wiki/Canonical_Huffman_code.   I did this logic on paper so I'll write it here. Let's say I have Huffman symbols and bit lengths (in order), A 3 K 3 H 4 S 4 L 5 M 5 N 5 O 5 Since the pseudo code given in the link does some addition operations, I am using integer to assign code = 0. So, the final canonical codes will be, A 0 K 1 H 4 S 5 L 12 M 13 N 14 O 15 Now, I want to convert these numbers into binary having their corresponding bit lengths as above so that I can use them to encode my file. So, these will become, A 000 K 001 H 0100 S 0101 L 01100 M 01101 N 01110 O 01111 As you can see, the numbers from H - O do not need the first 0 at MSB to be represented. But it is required for correctly encoding the file and this is where I'm stuck. I hope I made myself clear. If anyone can think of a solution (or alternative), I would really appreciate it. Thank you very much.
  10. Hi... I have tried to do this again and again but I'm failing to arrive at a solution. So I am posting here. Please bear with me. I want to take a number (declared preferably as int or char or std::uint8_t), convert it into its binary representation, then truncate or pad it by a certain variable number of bits given, and then insert it into a bit container (preferably std::vector<bool> because I need variable bit container size as per the variable number of bits). For example, I have int a= 2, b = 3. And let's say I have to write this as three bits and six bits respectively into the container. So I have to put 010 and 000011 into the bit container. So, how would I go from 2 to 010 or 3 to 000011 using normal STL methods? I tried every possible thing that came to my mind, but I got nothing. Please help. Thank you.
  11.   Yeah, I've moved on past that. I've already mentioned that I've been corrected on that matter. That's fine.       I thought about this a little... And came up with this. I don't know whether it is correct. for(int i = 0; i < Encoded_Data.size(); ++i) { if(Encoded_Data[i] == 1) { Packed_Byte |= 1; } ++Bit_Counter; if(Bit_Counter != 8) { Packed_Byte <<= 1; } if(Bit_Counter == 8) { Output_File << Packed_Byte; Bit_Counter = 0; } } Why I say this is because, even though I am getting my desired output now, somehow still some bytes are not matching. Here's a sample, From Hex Editor, 10100000 00100101 10001011 10110011 11010101 From Console Output, 10100000 00100101 10001011 10110011 01010101 As you can see, the fifth byte's first bit is 1 instead of 0. Any idea why?   EDIT: I forgot to reset the packed byte (Packed_Byte = 0) when I reset the bit counter. It is using the bit from the previous byte. Now it works perfectly. I also wrote the code for appending extra bits in order to write the last byte. I just have one last thing to do. I have to write the eof bit into the file. How would I do this? I couldn't find anything proper about it on googling.
  12. SOL, I did a couple of tests and found out that the vector<bool> works fine (at least in this particular instance). I tested to see which part of the code is causing the problem and found out it was the Bit_Counter part of the loop. Somehow it is not packing the bits correctly. I tried to write just one byte in the same loop and it works and everything fits. The output window, the hex editor, everything matches. I'm not able to see what's wrong. The operation syntax is correct. Here's the edited code which writes only byte perfectly, for(int i = 0; i < Encoded_Data.size() /*this is 8 bits long now*/; ++i) { if(Encoded_Data[i] == 1) { Packed_Byte |= 1; } if(i < Encoded_Data.size() - 1 /*naturally, this will be 7*/) { Packed_Byte <<= 1; } /*++Bit_Counter; if(Bit_Counter == 8) { Output_File << Packed_Byte; Bit_Counter = 0; }*/                        //this I removed completely } Output_File << Packed_Byte; Any idea why? I'm clueless. 
  13. This is my output bits code... It just overloads the << operator so that I can print a vector<bool> using std::cout. std::ostream& operator<<(std::ostream& os, std::vector<bool> Vec) { std::copy(Vec.begin(), Vec.end(), std::ostream_iterator<bool>(os, "")); return os; } And since I'm not writing any header or anything and just writing bits directly from the vector<bool>, I'm comparing the first 2-3 bytes of the file in the Hex Editor with the first 16-24 bits in the console output. It doesn't match. It worked with the test program I did above where I just write one byte to the file 256 times to create a 256 byte file. There was a match. Somehow, it's not working here.   However, please clarify me this... Is the code I wrote above correct? Am I missing anything, like a reversing operation or something like that? Or is the function perfectly fine? Please tell me, thank you for your time.
  14. OK... My code is not going to be portable. It's just for Windows. I can do what you have suggested, but is that the only reason why my output bits are not matching with the file bits or is it something related to my code. Am I doing any mistake in the code above? Please tell me. Thanks.
  15. Anybody...? Please help, guys. Any inputs are duly appreciated.   Sorry for the double post.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!