[QUOTE=Ziks;51849333]
Running out of things to do to avoid implementing static props.[/QUOTE]
That looks really nice, almost would look identical to how it looks in game in terms of lightmapping. I wonder what the current challenge is for parsing static props, at least in WebGL.
[QUOTE=atrblizzard;51853970]That looks really nice, almost would look identical to how it looks in game in terms of lightmapping. I wonder what the current challenge is for parsing static props, at least in WebGL.[/QUOTE]
Thanks! I've been avoiding doing static props because the MDL reader I wrote a little while back is a bit of a hack job, and I'll need to redo it which is a bit daunting.
Embedding my scripting language \o/
[img_thumb]https://hostr.co/file/yOBZ1zisRMKz/Screenshotfrom2017-02-2118-07-08.png[/img_thumb]
[QUOTE=Tamschi;51852962]Hold on to that code.
It may not work as general noise, but this looks like some amazing high-tech textile pattern.[/QUOTE]
Thanks, I usually try to keep my procedural noise code around when things go haywire. That's part of what makes programming noise stuff so much fun, half the time your bugs and errors turn out to be as interesting (or more so) than what you were shooting for anyways (e.g, when I made [URL="https://www.youtube.com/watch?v=jxlB1aDJpAM"]this[/URL] trying to make sun stuff).
IcedShot helped me out in the discord channel to find a few things that he thought (and I thought, too) might be causing the really extreme diamond-like artifacting I get with my simplex generator, but unfortunately these didn't fix the simplex issues. Still better to catch those bugs now rather than later though. The Perlin noise kernel and such got better though:
[t]https://raw.githubusercontent.com/fuchstraumer/CUDA_Noise/master/test.png[/t]
Its a bit full-bright-y now, and I'm not sure why values are being weighted to the top end. IcedShot also pointed out the fact that the ridges/lines appear near dark holes in the "background" noise gradient suggests some kind of logic error, and I have to agree. Both of these issues may have to do with my code for turning the raw floating point data into pixel data, but I'm not sure. I need to make sure to write better comments (I write most of them now with my much less experienced project partner in mind), document the functionality of the library and how it all works, and need to set this up for CMake, but the link to repo is [URL="https://github.com/fuchstraumer/CUDA_Noise/"]here[/URL] if anyone is interested. I'll repost it when the project is done too, might even post it to reddit because having my code utterly shredded by commenters there would actually be really educational (same applies for any criticism here and now as well).
[editline]21st February 2017[/editline]
ignore the fact, for example, that I somehow forgot to make destructors for the modules that call cudaMalloc, so yeah I kind of have a GPU memory leak and should probably quickly push a commit to fix that
[IMG]https://i.gyazo.com/1abd90732af601c1b659522a30d58b7b.gif[/IMG]
Our Preview window is like 50% of the way there! Now we've just gotta be able to actually draw the vector fields...
No content just yet but after my internship ended I got offered a job there, with some really good terms where I can work whatever hours I want, and since my school is 10 minutes from there I just go back and forth once a day.
They're busy changing from having everything on a single server to using Azure and multiple servers across the world. I basically can mess around with whatever I want and try to figure out what the best approach is and I'm enjoying myself a lot more than just sitting in school.
As a result of this I decided to spend a part of my first paycheck on something cool:
[t]http://i.imgur.com/6wPVzks.png[/t]
And I can't wait to get started with developing for VR!
Nothing is quite as nervewracking as seeing your sales go higher and higher while you've found a bug that will take at least a week to get on to the store and you're just [I]waiting[/I] for someone to find it and leave a shit review
Released version 1.0 of my ECS woo!
[QUOTE=WTF Nuke;51855725]Released version 1.0 of my ECS woo![/QUOTE]
Any link/info we can see?
[QUOTE=phygon;51856052]Any link/info we can see?[/QUOTE]
Oops yeah sure here you guys go: [url]https://github.com/Yelnats321/EntityPlus[/url].
I started working on improving vowels on female/child voices. It's surprisingly hard; you can't simply use the same formant ratios for all configurations, because the vocal tracts are built differently. So I've been adjusting the numbers by hand for the last few hours.
Man:
[vid]https://my.mixtape.moe/bgbtwz.wav[/vid]
Woman:
[vid]https://my.mixtape.moe/rinaoc.wav[/vid]
Child:
[vid]https://my.mixtape.moe/alznmc.wav[/vid]
[media]https://youtu.be/bWQlOJDE9ek[/media]
Warning- default youtube jazz
This is the network on mobile right now, with no netcode (positions are loaded straight from Firebase).
Pretty promising for the game, [I]very[/I] promising for the asset.
[QUOTE=Berkin;51857208]I started working on improving vowels on female/child voices. It's surprisingly hard; you can't simply use the same formant ratios for all configurations, because the vocal tracts are built differently. So I've been adjusting the numbers by hand for the last few hours.
//videos\\[/QUOTE]
You should make this aha.
[video=youtube;cmjrTcYMqBM]https://www.youtube.com/watch?v=cmjrTcYMqBM[/video]
Welp I rewrote boost::flat_map/set so that the library isn't dependent on boost but I don't trust my implementation enough to push the update.
[media]https://youtu.be/YuQw2kryADg[/media]
Screw you heightmaps. I cache triangles in 2d into a global 2d array of tri indices, then lookup which tris need to be searched for my current position, then do point in tri checks for those triangles, and finally interpolate (in 2d) the correct depth of the triangle
Whole lot of overcomplication, although I do get pixel perfect heightmaps out of the terrain like this. I'm lucky I have all the required tech just lying around, it only took me a couple of hours to get this to work because I just nicked it all from my OpenCL code. Performance is negligible, 0.003ms per lookup. Which isn't free, but its nearly free. I should get normals from the tris, set feet rotations, and then accurately set feet positions too instead of just using the body position
[editline]22nd February 2017[/editline]
Hardcore free XXX foot on terrain action, talk dirty to me
[IMG]https://dl.dropboxusercontent.com/u/9317774/footterrain.PNG[/IMG]
Look at those different feet heights. Absolutely mental. I'm off my face on foot -> terrain heights. How is such a thing even possible (I'm tired ok)
[editline]22nd February 2017[/editline]
[QUOTE=WTF Nuke;51858107]Welp I rewrote boost::flat_map/set so that the library isn't dependent on boost but I don't trust my implementation enough to push the update.[/QUOTE]
Testy test mc testerson? Honestly I wouldn't really ship my own implementation of a flatmap unless it was purely for internal use because people will break it. Even then, writing a properly compliant container is difficult
There must be an open source flatmap somewhere that you could provide with your library if you're not confident
[editline]22nd February 2017[/editline]
Today I embarked on a journey to network the trombone. I knew it was going to be complex, the trombone existed outside of the previously ordained networking system, and I didn't want to just keep piling things into the fighter already-megaclass-supernetworking model. I opened up the code, had to change my local ip because the new router firmware is completely broken, forwarded ports, fired up the game and master server, and checked that basic network connectivity was working. Bear in mind I haven't touched the networking for 5 months at this point (hooray illness)
It was at this point that I discovered that past me had already fully networked the trombone. Sounds were completely networked, and the trombones active state was networked as well. Interestingly I'd created a new extensible networking system for new kinds of networked variables that existed outside the scope of the regular fighter class (previously the only networked system), that made some kind of sense
Past me gets a gold fucking star for this one. This is the first time in a while that I haven't rolled my eyes at a system I created in the past, which is doubly surprising as I presumably created this when I was too tired to remember anything. Maybe I just thought it was all broken because alt tabbing switches back to the sword model (bug), so you can only verify it by having two copies running on different screens.
[editline]22nd February 2017[/editline]
Apparently nobody posts here anymore, so here's me playing around with a new feature I added (right click adds a major third)
[media]https://www.youtube.com/watch?v=4oOkUrSxZ2U[/media]
C++ Pro Tip: Do not let your type names exceed 100kb fully expanded.
This kills the linker.
[editline]22nd February 2017[/editline]
If anyone wonders what the hell I'm doing; I'm pretending C++ has a real fucking type system.
at this point, I'm thinking I should've just pulled some trickery and gone with "hey I rewrote my voxel engine in X hours", because this is a fucking drain. Learning interesting things though: message passing and event sharing is not a topic I had previously considered at all, and MineTest implements a pretty robust system for this (since its pretty moddable with Lua). There are some things they do that I don't like and won't implement (I think they could handle lighting better, instead of storing it constantly in each block).
On the topic of Blocks though, I made a colossal noob mistake with my block class: I had the [I]utterly fucking brilliant[/I] idea of making the main data member of my block class a pointer. That way I could just not create that member for air blocks and hopefully save some memory. Nevermind that that my main data member is a uint8_t, miniscule compared to the size of a pointer even on an x86 system, let alone x64. Oops. I kinda axed that.
What I did do instead, after some scathing criticism of the above idea, is create a block "description" struct that has a bunch of internal descriptive members that can describe things about a certain block type. Just provide this block type in the constructor, and the struct sets its members appropriately. This way getting block attributes is easy and can be done from several parts of my program, without requiring either a raw block instance or for me to bloat my block class with so many descriptors. Pretty basic stuff, but I'm proud of it :v:
[editline]edit[/editline]
as bad as it can be to pull a "rewrite everything!" approach, I really needed it. Lots of bad things about my previous "stable" version of this project, and I'm not trashing everything at least. I've also started looking back at my Mesh LOD attempts, since I should have the CUDA Noise project usable within the next few weeks. Once I can generate planetary terrain at reasonable time scales, I'm going to get back to work on my whole planet rendering project.
[QUOTE=Icedshot;51858127]Testy test mc testerson? Honestly I wouldn't really ship my own implementation of a flatmap unless it was purely for internal use because people will break it. Even then, writing a properly compliant container is difficult
There must be an open source flatmap somewhere that you could provide with your library if you're not confident[/QUOTE]
Yeah it is for internal use only, most functions are not implemented and all tests seem to be passing/benchmarks aren't showing much reduction in performance. I'll write more tests for the containers later though, it's not very fun to be honest.
[QUOTE=paindoc;51861555][...]
On the topic of Blocks though, I made a colossal noob mistake with my block class: I had the [I]utterly fucking brilliant[/I] idea of making the main data member of my block class a pointer. That way I could just not create that member for air blocks and hopefully save some memory. Nevermind that that my main data member is a uint8_t, miniscule compared to the size of a pointer even on an x86 system, let alone x64. Oops. I kinda axed that.
[...][/QUOTE]
Fun fact: This is [I]exactly[/I] how Minecraft used to do this (according to a Notch blog entry I can't find right now). I'm pretty sure they eventually rewrote that part, though.
I feel like you can point to literally any mistake in any voxel engine and minecraft would have done exactly that at some point.
[QUOTE=WTF Nuke;51862215]I feel like you can point to literally any mistake in any voxel engine and minecraft would have done exactly that at some point.[/QUOTE]
I actually misread it I just noticed (and considering MC was written in Java it wouldn't be possible this way).
The way Minecraft did it, in true Java enum fashion, was to handle blocks as pointers to singleton block type instances in memory (at least in function calls, with air being passed around as [I]null[/I]).
Considering that iirc you can't safely call anything on [I]null[/I] in Java, this caused some programming convenience issues.
[thumb]http://carp.tk/$/devenv_2017-02-23_10-02-02.png[/thumb]
Wrote a custom struct serializer/deserializer because i was not happy with default stuff. No attributes required.
[QUOTE=WTF Nuke;51862215]I feel like you can point to literally any mistake in any voxel engine and minecraft would have done exactly that at some point.[/QUOTE]
I'm pretty sure I'm doing the same thing, making every mistake possible, except the end game for me is not lodsemone
I got rejected by my universities EE department last week. I kinda moped about it, mostly because I'm out of options at this uni. I'm asking my boss if I can stay on through the spring (I was probably coming back for summer already), as I'm going to be saving money. New plan is just go to a local CC for a CSE degree, since I can "restart" there.
Figure I live in Seattle, the market is in a good shape and my portfolio of work should be even better given six more months at my current position and six more months of independent work
[editline]23rd February 2017[/editline]
I tell you what's fun: passing structs to the GPU with Cuda D:
[QUOTE=Tobba;51860567]C++ Pro Tip: Do not let your type names exceed 100kb fully expanded.
This kills the linker.
[editline]22nd February 2017[/editline]
If anyone wonders what the hell I'm doing; I'm pretending C++ has a real fucking type system.[/QUOTE]
Should've gone with Haskell...
[QUOTE=paindoc;51863015]
I tell you what's fun: passing structs to the GPU with Cuda D:[/QUOTE]
Unless your struct has pointers I don't see how that's a problem.
[QUOTE=alien_guy;51864840]Unless your struct has pointers I don't see how that's a problem.[/QUOTE]
Alignment issues will probably provide you with all kinds of cancer, differences in how structs are packed can provide hours of fun!
FUN FOR THE WHOLE FAMILY, CALL 1-800-ALIGNMENT NOW :scream:
[QUOTE=Profanwolf;51864921]Alignment issues will probably provide you with all kinds of cancer, differences in how structs are packed can provide hours of fun!
FUN FOR THE WHOLE FAMILY, CALL 1-800-ALIGNMENT NOW :scream:[/QUOTE]
Yes, this exactly. CUDA is hitler about alignment. Its causing me to get random, indecipherable, mysterious alignment issues when I try to build in release mode. Somehow, my generated texture works fine in debug but reading from it fails completely with 30-64 (whole blocks of threads failing) to read from it due to misaligned loads or stores. And that's just me filling an array of 32-bit floats.
I think C++ fucks around with alignment and such for optimization purposes, which breaks things with CUDA. I'm not sure what the alignment requirements are, exactly, or how to ensure things are aligned, and the API documentation isn't terribly helpful in this respect and neither are the official examples. So even though I can specify struct member alignment in the C++ compiler, I'm not sure how compliant NVCC will be with this in turn.
I mentioned it in the discord, but my attitude nears [URL="https://youtu.be/_36yNWw_07g?t=6"]THIS[/URL] more and more every day I work with CUDA. Their examples are shotgunned across using the Driver API, the Runtime API, different API versions, pure C99, C++14/11/whateverthefucktheylike, Modern OpenGL, old OpenGL, and so on. The API also lacks MAJOR fucking features, like the vector operators issue I mentioned. Oh, and Geforce experience and Nvidia's rapid-fire driver releases as of late cause complete pandemonium from time to time, Nvidia Nsight is useless for CUDA it feels (really limited debugging facilities, I'm having to learn to read assembly at this point D:), and there is rarely a response from CUDA devs on Nvidias forums or through their official email.
People that say GPGPU computing is "the future" aren't disclosing that the future is real fucking grimdark, because half the time I feel like a fucking member of the Adeptus Mechanicus attempting to worship the machine god that is my GPU
I generally use C++ AMP because its most comfortable to work with by a mile, and just have defines to turn it off and then i can debug it from the CPU.
If i ever have to optimize gpu programs or port it to a different platform ill port it to a different GPGPU platform when its done.
[cpp]
typedef struct alignas(2*sizeof(float)) point {
float x;
float y;
float z;
} point;
[/cpp]
Afaik in cuda I think this is all you need?
so how did I manage all my cuda stuff having forgotten alignment was a thing until just now.
Alignment in OpenCL (which i suspect is the same as CUDA):
Types are self aligned (ie a cl_float4 exists on a 4*4 byte boundary), and follows c structure padding rules that result from this
[cpp]
struct i_hate_gpgpu
{
float data_member; ///start on 0
int padding[3]
cl_float4 data_member_2; ///must start on a 4*4 byte boundary
short data_member_3;
short padding_2;
short2 data_member_4;
int2 padding_3;
cl_float3 data_member_5; ///lol jk float3 doesn't exist its a float4
///any extra padding.. lets see, the struct has to be a multiple of the largest element right
///we have 16*4 bytes so far, which is a multiple of cl_float4s size so we're fine
};
[/cpp]
But obviously padding doesn't exist here, they're hidden variables. OpenCL provides cl_float4/etc types which come with alignment tags so you don't run into issues and it mostly sorts itself out
Padding *is* implementation defined, so the C++ runtime can do whatever it wants, which is why opencl types are so useful for structs
[editline]bum[/editline]
[QUOTE=Cold;51865215]I generally use C++ AMP because its most comfortable to work with by a mile, and just have defines to turn it off and then i can debug it from the CPU.
If i ever have to optimize gpu programs or port it to a different platform ill move it to a different GPGPU platform then.
[cpp]
typedef struct alignas(2*sizeof(float)) point {
float x;
float y;
float z;
} point;
[/cpp]
Afaik in cuda I think this is all you need?[/QUOTE]
Only needs to be aligned to float AFAIK right? The floats need to be aligned on a 4 byte boundary, so 2*float is 'too' much. Not that it probably matters
Sorry, you need to Log In to post a reply to this thread.
